1211106 - Startup cache performs many small read operations

Status: NEW

(Core :: XPCOM, defect, P3)

Description

[Gregory Szorc [:gps]]

Same deal as bug 1211090 but for <Profile>/startupCache/startupCache.8.little. Lots of read system calls that look like:

  read(9)
  read(46)
  read(<something between 60 and 160>)

Sequential file reads via system calls should be performed in chunks so we perform fewer system calls and complete faster.

On my modern machine with an SSD, it took 1,138 read system calls to read 54,614 bytes from the aforementioned startup cache file. This took ~100ms. Other read operations in Firefox are fetching in 32kb or 64kb chunks and return in <10us (that's 0.01ms, or 10,000x faster). 100ms isn't a whole lot. But excess is excess. And given "startup" is in the file name, I reckon this can't help startup performance, especially on machines that aren't as modern as mine.

2015-11-02 64-bit Nightly on Windows 10.

Comment 1

[:Gijs (out for now; he/him)]

This seems to all be backed by nsZipItem, but it looks like it might write to the same file from a different thread, and so I don't know how easy it would be to read more than required and reuse that data.

Looks like froydnj and jchen have touched this in recent history, so let's ask them.

(Sidenote: Jim, did you file that followup for bug 1163719 comment 7 ?)

Comment 2

[Nathan Froyd [:froydnj]]

I'd guess this is somewhere in the zip code, as that'd be what's responsible for doing the reads.  I'm unsure of how much works it'd take to get the zip code to read files in larger chunks...

I can look a little further, but probably not until next week.

Comment 3

[Nathan Froyd [:froydnj]]

Setting ni? to remind myself to look at this.

Comment 4

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to :Gijs Kruitbosch from comment #1)
> This seems to all be backed by nsZipItem, but it looks like it might write
> to the same file from a different thread, and so I don't know how easy it
> would be to read more than required and reuse that data.
> 
> Looks like froydnj and jchen have touched this in recent history, so let's
> ask them.

I think it should be okay. AFAIU startupcache prevents reading from and writing to the archive at the same time. Taking a quick look at nsZipArchive, zip archive itself should be mmapped though, so not sure why that's generating that many reads. Maybe it's the zip writer that's doing the reads, when we are writing to the archive.

> 
> (Sidenote: Jim, did you file that followup for bug 1163719 comment 7 ?)

I did not. Feel free to file it.

Comment 5

[Nathan Froyd [:froydnj]]

Time to admit I'm not going to look at this.