Closed Bug 818725 Opened 8 years ago Closed 3 years ago

Flush localStore.rdf off the main thread

Categories

(Core Graveyard :: RDF, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: vladan, Assigned: wchen)

References

(Blocks 2 open bugs)

Details

(Keywords: main-thread-io, Whiteboard: [Snappy:P2])

We should look into flushing the localStore.rdf file off the main thread on shutdown:

http://people.mozilla.com/~bgirard/cleopatra/#report=1ecd7a421948995171a4bb483b7bcc8e1868cc57
I'm new to the topic, what would that mean? code wise, and in terms of "written file to disk before shutdown" etc.

If I read the profile right, we're actually spending time in ::Flush, i.e., not in RDF itself, but only in the actual finish of the disk write?

Is that true for various sizes of localstore.rdf?
@Axel: I believe that this is a general issue with flushing. Its duration is unbounded, regardless of the size of the file.
No longer blocks: start-faster
Whiteboard: [Snappy:P2]
William's going to work on this.
Assignee: nobody → wchen
I took a look into this and I don't think it's worthwhile to move Flush() off the main thread.

RDF serialization, where the Flush() spends most of its time, uses a lot of main-thread only objects (RDFService, RDFXMLDataSource, ContainerEnumerator, nsStandardURL and likely many more that I haven't discovered). For some of these objects, we can use runnables to do what we need on the main thread while other objects will probably have to be converted to be fully thread-safe. We don't have good test coverage of this code so such a major change is risky.

Also, this is legacy code and we don't use localStore.rdf for Gecko anymore. It looks like only extensions use this (and the problem only exhibits itself when a lot of data gets stored into localStore.rdf, causing subsequent flushes to be slow). This problem should also go away by itself in version 57 since extensions will no longer be able to write into the file.

For these reasons I'm marking this bug as WONTFIX.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Also see bug 987728 comment 11.  It turns out that the recent spike in signatures involving code around this in our BHR data was due to the TabMixPlus add-on, not anything caused by our code.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.