User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 The dyld shared cache lives in /var/db/dyld/. The two files of interest are dyld_shared_cache_i386.map (for x86-32) and shared_region_roots/Applications.paths. Both are regular text files. The former shows the contents of the shared cache for the i386 architecture and the latter is what update_dyld_shared_cache inspects. There's no prebinding on newer versions of Mac OSX and the dyld shared cache is automatically updated as needed. Tracing Safari disk activity during startup reveals that basically all its dynamic libraries are pulled from the dyld shared cache. It's possible to add Firefox (.../Firefox.app/Contents/MacOS/firefox-bin) to Applications.paths and the change will be kept across reboots. Unfortunately, only a handful of libraries that Firefox uses are pulled into the cache by update_dyld_shared_cache. I'm speculating that this may have something to do with @executable_path/XUL and friends (otool -L .../firefox-bin). Safari uses absolute paths to frameworks in /System/Library/Frameworks so I speculate that relative paths are what is preventing XUL and others from going into the cache. We may want to investigate /System/Library/Frameworks/Firefox.framework or similar. Notes: https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements/joelr_notes Reproducible: Always

Try as I might, I cannot get XUL into the dyld shared cache. It may not matter, though. dyld reports roughly the same dynamic linking time for Firefox with its large number of separate dynamic libraries and Safari which pulls everything out of the cache. I'm clearly missing something somewhere but I can't put my finger on it. I updated my notes with my latest findings. https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements/joelr_notes#August_27.2C_2009

Dynamic linking time for cached Safari is about the same as for uncached Firefox but Safari still starts much faster. The performance bottleneck is then somewhere else. Also, the cache is supposed to be for frequently used system-wide libraries, although Safari sticks jscore.dylib in there. I floated the idea of sticking Firefox into the shared cache in front of some people, including apple devs and they seemed to be strongly against it. One objection is "what happens if all apps decide to stick themselves into the cache?". Another objection is that Firefox would require an installer with root password prompt to be able to update the shared cache. I decided to leave the shared cache for last. We can try to squeeze one last drop of performance with the shared cache, once we are starting up as fast as Safari.

(In reply to comment #2) > I floated the idea of sticking Firefox into the shared cache in front of some > people, including apple devs and they seemed to be strongly against it. One > objection is "what happens if all apps decide to stick themselves into the > cache?". wah. then don't make it public, or lead by example. > Another objection is that Firefox would require an installer with root > password prompt to be able to update the shared cache. getting closer to this: http://limi.net/articles/firefox-mac-installation-experience-revisited/. > I decided to leave the shared cache for last. We can try to squeeze one last > drop of performance with the shared cache, once we are starting up as fast as > Safari. can you ballpark estimate what benefit we'd get from this?

I don't think the cache will make a difference. My take is that most of the libraries used by Safari are cached by the OS, i.e. there's not a myriad of custom libraries that Firefox uses. Safari doesn't have a plugin system either. I measured dynamic linking time before. Dynamic linking time for cached Safari is about the same as for uncached Firefox but Safari still starts much faster. The performance bottleneck is then somewhere else.

I should also mention that I tried disabling the dyld cache entirely during my testing. It did affect the startup time of Firefox and Safari because the system libraries weren't cached. The Mac OSX dynamic linker is wicked fast, though, at least on Leopard, and we are not spending a lot of time in this phase of startup.

per joel's notes (https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements/joelr_notes#August_27.2C_2009) dynamic linking takes less than a second. while there maybe be a win here, it's not a high priority.

(In reply to comment #6) > dynamic linking takes less than a second. to further clarify: that's out of 10 seconds on a cold startup.

(In reply to comment #2) > Also, the cache is supposed to be for frequently used system-wide libraries, > although Safari sticks jscore.dylib in there. WebKit and JavaScriptCore are both system-wide libraries -- they both have stable API+ABI and are used by many different applications and have been for years.