Open Bug 842777 Opened 11 years ago Updated 2 years ago

preload webappsstore.sqlite on first access to warm cache + use CHUNK_SIZE of 1meg

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86_64
Windows 7
defect

Tracking

()

People

(Reporter: taras.mozilla, Unassigned)

References

Details

(Whiteboard: [Snappy:P1])

I'm consistently getting webappsstore.sqlite showing up >100ms.

We should preload databases(up to a certain size?) with readahead. Might need metrics help to verify that this is indeed a win.
p1 because main thread io
Whiteboard: [Snappy:P1]
This is what my new dom storage code is doing.  See https://bugzilla.mozilla.org/show_bug.cgi?id=600307#c91 how it works.
(In reply to Honza Bambas (:mayhemer) from comment #2)
> This is what my new dom storage code is doing.  See
> https://bugzilla.mozilla.org/show_bug.cgi?id=600307#c91 how it works.

I mean low-level os readahead like in http://dxr.mozilla.org/mozilla-central/xpcom/glue/standalone/nsGlueLinkingWin.cpp#l40 We should do this the first time we access the db
I also see that the localstorage db can get fragmented.
Summary: preload webappsstore.sqlite on first access to warm cache → preload webappsstore.sqlite on first access to warm cache + use CHUNK_SIZE of 1meg
(In reply to Taras Glek (:taras) from comment #3)
> (In reply to Honza Bambas (:mayhemer) from comment #2)
> > This is what my new dom storage code is doing.  See
> > https://bugzilla.mozilla.org/show_bug.cgi?id=600307#c91 how it works.
> 
> I mean low-level os readahead like in
> http://dxr.mozilla.org/mozilla-central/xpcom/glue/standalone/
> nsGlueLinkingWin.cpp#l40 We should do this the first time we access the db

Aha.  At [1] we determine the file name, this is on the main thread soon after session-restore.  At [2] we are opening the database, this already happens on the background thread.

Is the proper place [1] on the main thread or some time before [2] on the bck thread?


[1] https://hg.mozilla.org/try/annotate/b97bcbab7e40/dom/src/storage/DOMStorageDBThread.cpp#l55
[2] https://hg.mozilla.org/try/annotate/b97bcbab7e40/dom/src/storage/DOMStorageDBThread.cpp#l358
this should happen at [2]

aklotz has some generic readahead utility function wip somewhere.
Assignee: nobody → aklotz
(In reply to Taras Glek (:taras) from comment #6)
> this should happen at [2]
> 
> aklotz has some generic readahead utility function wip somewhere.
This has now landed in m-c. Take a look at the ReadAhead* functions in xpcom/glue/FileUtils.h
Assignee: aklotz → nobody
Please, consider work on this bug to happen for the new code from bug 600307.  I am starting push on that bug and it would be better to spend resource on these optimization for the new code rather.  Thanks.
Component: DOM: Other → DOM
Is this work worth doing still?
I think it is.  But I have no estimation or time to work on this.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.