Firefox/Projects/Startup Time Improvements/joelr notes: Difference between revisions

Jump to navigation Jump to search
No edit summary
Line 7: Line 7:
=== August 27, 2009 ===
=== August 27, 2009 ===


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.  
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.
 
[https://bugzilla.mozilla.org/show_bug.cgi?id=513076 Bug 513076].


= Previous statuses =  
= Previous statuses =  
109

edits

Navigation menu