[GHC] #11587: Place shared objects in LIBDIR

[GHC]

#11587: Place shared objects in LIBDIR
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Package system    |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by trommler):

 I think the real issue is that Haskell's libraries are all in different
 directories and so the dynamic linker must read at least one directory and
 one file for each Haskell dynamic library.

 The quadratic time required to find a library seems to be small compared
 to the disk access to read all directories in the `RPATH` from the hard
 disk. The second read of a directory would most of the time hit the file
 system cache.

 I tried this experiment on my x86_64 Linux machine (still using spinning
 hard drives) with a dynamically linked GHC:
 {{{
 $ time ghc --version
 The Glorious Glasgow Haskell Compilation System, version 7.10.3

 real    0m4.805s
 user    0m0.044s
 sys     0m0.080s
 $ time ghc --version
 The Glorious Glasgow Haskell Compilation System, version 7.10.3

 real    0m0.048s
 user    0m0.024s
 sys     0m0.024s
 }}}

 Given these numbers I am in favour of @bgamari's original suggestion. If
 we do not want to clutter GHC's `$LIBDIR` then we could still put all
 Haskell dynamic libraries into one subdirectory with O(1) time cost.

 The solution in comment:4 could be implemented in Linux (and ELF in
 general) too but I think performance would be as bad (at least when disk
 access is slow). To open `foodir/libbar.so` the runtime linker still needs
 to read `foodir` and then read `libbar.so`.

 IIRC, GHC 8.0 does not encode the ABI hash in the dynamic library's file
 name anymore but has it only in the package's directory name. We will need
 to revisit that decision.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11587#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler