22 ms·

Hmmm, so I suspect in practice that you're not going to see this kind of difference usually - since he's probably testing on a binary he just built, SuperFetch

Hmmm, so I suspect in practice that you're not going to see this kind of difference usually - since he's probably testing on a binary he just built, SuperFetch (the built in OS prefetcher) hasn't had a chance to determine what pages are usually used by Firefox. Once you've used FF as your browser for awhile, SuperFetch will know better and won't do as badly. That being said, this trick will probably beat SuperFetch, since they know up front that they'll be using big chunks of xul.dll. Don't do this in every app though, or else every app in the system is just chewing through IOs on pages they might not actually be using.

holygoat 16y ago
No, it won't have a big effect on warm or OS-optimized startup time... but cold startup time, especially for new releases, is a big area of concern, so it's nice to see wins there!
- simcop2387 16y ago
  While I doubt my specific hypothetical case will actually exist... I think it should also help if the OS has decided not to prefetch the dll for you for some reason. I don't believe it should ever actually hurt but should make it a lot nicer on any of the possible edge cases.
slightlyoff 16y ago
SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries. I implemented a similar solution for chrome.dll last summer and it had a gigantic effect on cold start times. Glad to see Mozilla prioritizing startup too.
- asadotzler 16y ago
  Alex, can you link the bug(s) or patch set for your similar changes?
  - mihaip 16y ago
    http://crbug.com/45510 http://crbug.com/45510, http://crrev.com/50386 http://crrev.com/50386, http://crrev.com/51486 http://crrev.com/51486, http://crrev.com/51594 http://crrev.com/51594 and http://crrev.com/54934 http://crrev.com/54934 seem to be appropriate links.
  - slightlyoff 16y ago
    Mihai covered it. Here's my rundown: http://infrequently.org/2011/01/on-the-care-and-feeding-of-spinning-disks/ http://infrequently.org/2011/01/on-the-care-and-feeding-of-s...
- JonnieCache 16y ago
  >SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries Yuck. Is there a good engineering reason for this reliance on the physical location of code within a lib file rather than its logical internal structure? I guess its a compromise they made after running some studies. Still seems sickeningly ugly though. Just like the trick the OP was forced to implement to override this behaviour. Yucketty yuck yuck.
  - slightlyoff 16y ago
    Define "logical internal structure"? Most code in a library won't be differentiated by use unless you can provide WPO or PGO-based feedback that you trust as representative. As for the next obvious question ("why not just read in the whole thing?"), I think you can probably guess. I'm not sure how yucky this is. The world is analog. MSFT made things go faster without asking developers to change anything they were doing. I wish more OSes showed more of this sort of user-centric, data-driven prioritization of feature development.
    - JonnieCache 16y ago
      I am clearly much less qualified to speak on this subject than you so I defer to you on this one. All I meant by 'yuck' was that in my limited experience with computer science, whenever there is a solution that involves as blunt a compromise as 'cache the first 10 megabytes,' it isn't usually too long before that solution is known as the 'naive' solution.
- xpaulbettsx 16y ago
  Interesting. I've worked on SuperFetch and I didn't know that!
  - slightlyoff 16y ago
    It's likely that my understanding of the situation is at least partially confused. The "SuperFetch" branding covers a lot of systems with some observably complex interactions. From my recollection of the XPerf traces, we saw misses 10+ MB back in the DLLs and just ascribed it to "SuperFetch" on the front half. If you could tell me if that's causal, it'd be awesome = )

holygoat 16y ago

No, it won't have a big effect on warm or OS-optimized startup time... but cold startup time, especially for new releases, is a big area of concern, so it's nice to see wins there!

simcop2387 16y ago
While I doubt my specific hypothetical case will actually exist... I think it should also help if the OS has decided not to prefetch the dll for you for some reason. I don't believe it should ever actually hurt but should make it a lot nicer on any of the possible edge cases.

slightlyoff 16y ago

SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries. I implemented a similar solution for chrome.dll last summer and it had a gigantic effect on cold start times. Glad to see Mozilla prioritizing startup too.

asadotzler 16y ago
Alex, can you link the bug(s) or patch set for your similar changes?
- mihaip 16y ago
  http://crbug.com/45510 http://crbug.com/45510, http://crrev.com/50386 http://crrev.com/50386, http://crrev.com/51486 http://crrev.com/51486, http://crrev.com/51594 http://crrev.com/51594 and http://crrev.com/54934 http://crrev.com/54934 seem to be appropriate links.
- slightlyoff 16y ago
  Mihai covered it. Here's my rundown: http://infrequently.org/2011/01/on-the-care-and-feeding-of-spinning-disks/ http://infrequently.org/2011/01/on-the-care-and-feeding-of-s...
JonnieCache 16y ago
>SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries Yuck. Is there a good engineering reason for this reliance on the physical location of code within a lib file rather than its logical internal structure? I guess its a compromise they made after running some studies. Still seems sickeningly ugly though. Just like the trick the OP was forced to implement to override this behaviour. Yucketty yuck yuck.
- slightlyoff 16y ago
  Define "logical internal structure"? Most code in a library won't be differentiated by use unless you can provide WPO or PGO-based feedback that you trust as representative. As for the next obvious question ("why not just read in the whole thing?"), I think you can probably guess. I'm not sure how yucky this is. The world is analog. MSFT made things go faster without asking developers to change anything they were doing. I wish more OSes showed more of this sort of user-centric, data-driven prioritization of feature development.
  - JonnieCache 16y ago
    I am clearly much less qualified to speak on this subject than you so I defer to you on this one. All I meant by 'yuck' was that in my limited experience with computer science, whenever there is a solution that involves as blunt a compromise as 'cache the first 10 megabytes,' it isn't usually too long before that solution is known as the 'naive' solution.
xpaulbettsx 16y ago
Interesting. I've worked on SuperFetch and I didn't know that!
- slightlyoff 16y ago
  It's likely that my understanding of the situation is at least partially confused. The "SuperFetch" branding covers a lot of systems with some observably complex interactions. From my recollection of the XPerf traces, we saw misses 10+ MB back in the DLLs and just ascribed it to "SuperFetch" on the front half. If you could tell me if that's causal, it'd be awesome = )