4 ms·
From my observations multi-threading the linker would be more useful, since for small changes in bigger projects the linking step usually takes a lot longer tha
by blattimwind 7y ago
From my observations multi-threading the linker would be more useful, since for small changes in bigger projects the linking step usually takes a lot longer than compiling a couple units.
- tacostakohashi 7y agoThere exists a multi-threaded linker called gold.
- ndesaulniers 7y agoLLD (llvm's linker) is also threaded but much faster than gold.
- ef004 7y agoIve never found linking to take more than 5 seconds with the standard linker which, but lld exists and its super fast in my experience. But i guess its only needed whon working on huge c++ like firefox or sth. like that. https://lld.llvm.org/ https://lld.llvm.org/
- barrkel 7y agoLinking is isomorphic to tracing, moving GC. Effectively, the linker relocates objects in memory and writes a freeze-dried "heap" for the OS loader (another linker) to page in later. Linker slowness ~= GC pause. The cost is approximately proportional to the size of the traced graph.
- kardos 7y agoIn a similar vein, not all units cost the same to compile -- even with many jobs in a make -j situation, toward the end of the build there may be only a few units still in progress. These lengthy 'stragglers' might benefit the most from this parallelism and consequently reduce total compile time. Quite looking forward to this project landing in a stable release. On the topic of linking-- can you sub in the gold linker for faster linking in your projects?
- seamyb88 7y agoI also find that the linker is the issue. Yes for performance, but also for testing (to the point of failure) linux's 'out of memory' scenario (try make -j8 on the llvm source, for example).