
#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