3 ms·

> isn't this only true for the first time a function is used? Yes, but it will happen each time the program loads, which means your LD_* variables will get par

> isn't this only true for the first time a function is used? Yes, but it will happen each time the program loads, which means your LD_* variables will get parsed/iterated over. Statically linking stuff in can help if you have a program that needs to be exec()'d in a loop. While it'll probably only shave off 0.001 seconds per exec() call it can add up, more so if you have LD_LIBRARY_PATH set to look on some slow storage like nfs. But its a bit of a hyper optimization at that point. I've used this to really annoy a c++ developer saying c++ was faster than c. Evil trick on my part but my euler solutions were always faster. >.<

state_less 9y ago
Side Note: Nice to see you here. Thanks for your Alpine GHC package :) My Scotty+Haskell+Alpine service is the lightest container in the fleet. It's only using 1.3 MiB of RAM!
- mitchty 9y ago
  You're welcome! I made it more because I wanted a static pandoc binary. The rest came along for the ride, glad to hear its of use! That said I really need to get back to debugging the segfault in building ghc 8.2.2 on armhf in the ghc rts. But its gotten me going through everything but ghc and whatnot. Annoying when things worked before and don't now. Even weirder that only the final stage build is at issue, the other two are fine.