109
edits
Firefox/Projects/Startup Time Improvements/joelr notes: Difference between revisions
Jump to navigation
Jump to search
Firefox/Projects/Startup Time Improvements/joelr notes (view source)
Revision as of 12:25, 28 August 2009
, 28 August 2009→August 27, 2009
Joel Reymont (talk | contribs) |
Joel Reymont (talk | contribs) |
||
| Line 15: | Line 15: | ||
It's possible to add Firefox (''.../Firefox.app/Contents/MacOS/firefox-bin'') to | It's possible to add Firefox (''.../Firefox.app/Contents/MacOS/firefox-bin'') to | ||
Applications.paths and the change will | Applications.paths and the change will persist across reboots. Unfortunately, | ||
only a handful of libraries that Firefox uses are pulled into the cache by | 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 | '''update_dyld_shared_cache'''. I'm speculating that this may have something to do | ||
| Line 26: | Line 26: | ||
[https://bugzilla.mozilla.org/show_bug.cgi?id=513076 Bug 513076]. | [https://bugzilla.mozilla.org/show_bug.cgi?id=513076 Bug 513076]. | ||
It's possible to fix relative library paths in a given library, e.g. ''fix.sh XUL'' where ''fix.sh'' looks like this | |||
<pre> | |||
#!/bin/bash | |||
function dylibs () { | |||
otool -L $1 |grep executable_path|awk '{print $1}'|cut -d"/" -f2 | |||
} | |||
for i in `dylibs $1` | |||
do | |||
install_name_tool -change @executable_path/$i `pwd`/$i $1 | |||
done | |||
install_name_tool -id `pwd`/$1 $1 | |||
</pre> | |||
Firefox has to be recompiled with ''LDFLAGS=-header-pad_max_install_names'' in ''MOZCONFIG'' to make this happen since new library paths are greater than the space allocated in the Mach-O binary. See the man page for '''install_name_tool''' for details. | |||
It's possible to force dynamic libraries into the cache by putting dynamic library paths into '''shared_region_roots/Applications.paths''' instead of executables. I wasn't successful in caching XUL, though, regardless of what I did. | |||
In the end it doesn't seem to matter since there's a baffling lack of difference between Firefox and Safari cold stats, despite Safari pulling everything from the cache and Firefox using a large number of non-cached dylibs. | |||
Here's the cold startup stats for Safari | |||
<pre> | |||
sync && purge && DYLD_PRINT_STATISTICS=1 /Applications/Safari.app/Contents/MacOS/Safari | |||
total time: 696.9 milliseconds (100.0%) | |||
total images loaded: 116 (114 from dyld shared cache, 114 needed no fixups) | |||
total segments mapped: 5, into 30 pages with 10 pages pre-fetched | |||
total images loading time: 204.9 milliseconds (29.4%) | |||
total rebase fixups: 1,298 | |||
total rebase fixups time: 0.1 milliseconds (0.0%) | |||
total binding fixups: 2,476 | |||
total binding symbol lookups: 234, average images searched per symbol: 1.6 | |||
total binding fixups time: 80.5 milliseconds (11.5%) | |||
total bindings lazily fixed up: 3 of 901 | |||
total init time time: 411.3 milliseconds (59.0%) | |||
total images with weak exports: 1 | |||
</pre> | |||
and Firefox | |||
<pre> | |||
total time: 731.2 milliseconds (100.0%) | |||
total images loaded: 106 (93 from dyld shared cache, 56 needed no fixups) | |||
total segments mapped: 49, into 5903 pages with 684 pages pre-fetched | |||
total images loading time: 235.3 milliseconds (32.1%) | |||
total rebase fixups: 149,011 | |||
total rebase fixups time: 3.7 milliseconds (0.5%) | |||
total binding fixups: 24,932 | |||
total binding symbol lookups: 797, average images searched per symbol: 2.3 | |||
total binding fixups time: 149.9 milliseconds (20.5%) | |||
total bindings lazily fixed up: 45 of 19,109 | |||
total init time time: 342.2 milliseconds (46.8%) | |||
total images with weak exports: 3 | |||
</pre> | |||
Notice a large and significant difference? Me neither. | |||
The other thing that I cannot explain at the moment is where the rest of the startup time goes, e.g. | |||
<pre> | |||
./cold.sh startup.d | |||
Total: 10001.723521ms | |||
</pre> | |||
So it took less than 1 second to dynamically link Firefox but where did the other 9 seconds of startup go? | |||
cold.sh is rather simple | |||
<pre> | |||
#!/bin/bash | |||
cmd="./Minefield.app/Contents/MacOS/firefox-bin -no-remote -foreground -P 2" | |||
sync && purge && dtrace -x dynvarsize=64m -x evaltime=exec -c "$cmd" -wZs $1 | |||
</pre> | |||
and the startup.d script doesn't do much either | |||
<pre> | |||
#pragma D option quiet | |||
BEGIN | |||
{ | |||
start = timestamp; | |||
} | |||
/* stop tracing here */ | |||
mozilla$target:::main-entry | |||
{ | |||
exit(0); | |||
} | |||
END | |||
{ | |||
this->total = timestamp - start; | |||
printf("Total: %u.%06ums\n", this->total / 1000000, this->total % 1000000); | |||
} | |||
</pre> | |||
I don't have an explanation yet but 9 seconds is a very large difference. | |||
= Previous statuses = | = Previous statuses = | ||