https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #5) > 1) Speculation: that there are a lot of paths to search and they might > contain many files, so that if there's no caching of the results (perhaps > that was present pre-SIP and is now removed) .. it could mean a lot of work > to find the libgcc_s - that's the last path in the list. > > * To test this hypothesis, I'm going to experiment with re-ordering the > search path (temporary fix). So some experiments * average GCC build time difference (loaded machine, 80% of threads in use) - 3:1 * variation is quite high - from 3:1 - 20:1 if one just does a single configure operation repeatedly (I speculate that when dyld is busy, then things slow down). * Removing all but the GCC path, more or less behaves the same as an empty DYLD_LIBRARY_PATH * However, simply re-ordering the paths doesn't seem to be effective, so I speculate that it's the process of searching the paths for libs that are _not_ found (and therefore then picked up from their usual place) that's the time sink
