Folks,
I'm tasked with improving Firefox startup performance on Mac OSX.
Is there a way to find out what pages of a file are in the filesystem
cache?
Is this a good list to discuss IO performance?
Joel,
This is a good list for the discussion in that a number of the folks that understand your problem are here.
Unfortunately, you're headed in a bad direction with your first question. Various folks have started prodding you in the right direction; I'm going to take a similar tack.
Firstly; have you mapped all of the files that are accessed during Firefox' startup (both cold and hot) on MacOS X (note correct spacing for those that care)?
You can use the fs_usage command to track filesystem operations, both for the Firefox process itself, as well as other system services on which it depends. Understanding the nature of the relationship with those other processes is important (some are synchronous and block Firefox' internal progress during startup, others are asynchronous and just present additional load to the system). You may find that working at a higher level using Instruments with the File Activity instrument and others gives you a broader perspective and better time correlation with other activity in the system.
Once you've done this and mapped the operations to their instigators in the Firefox startup path, you can start looking for low-hanging fruit. Note that understanding what's in the cache is really not very important unless you expect that your working set between now and the time you hit the files in the cache will exceed available memory - in which case you're already behind the eightball. It is more important for you to look at opportunities to avoid doing any more I/O up front than you must, and doing that I/O in the most efficient manner possible.
Terry's obscure comment about static constructors refers to the fact that a large C++ design with many static class instances can spend a very large amount of time running almost completely serialised as it processes C++ constructors. This is almost always bad for startup performance; the __TEXT,__StaticInit section in the XUL object isn't tiny, so there may be some room for improvement here. Note that this almost always has higher-level implications, but the upside is that it's a win for everyone.
With regards to optimising file I/O, there isn't a lot different between MacOS and any other system; it's always better to read large files sequentially, large reads are better than small reads, buffered I/O is a bad way to read large amounts of data, reading data more than once is cheap but not free, etc. etc. File offset locality of reference helps (files on HFS are almost always contiguous) but directory locality of reference less so (as the namespace is sorted for lookup, not by sibling proximity). File birthtime locality of reference tends to be good (files created near to one another temporally tend to be near one another on the disk).
HTH somewhat. If you can share some of your observations to date, we might be able to adjust the fairly general advice so far into something more actionable...
= Mike
-- True terror is to wake up one morning and discover that your high school class is running the country. -- Kurt Vonnegut
|