1361095 - [meta] Can nsContentPrefService avoid main thread IO before the first window is shown?

Status: NEW

(Firefox :: General, enhancement, P3)

Description

[Florian Quèze [:florian]]

See this profile captured during startup on the quantum reference hardware: https://perfht.ml/2p1EDjb

51ms of startup is waiting for a CreateFileW system call from mozilla::storage::Service::OpenDatabase / ContentPrefService__dbInit.

Comment 1

[(no longer active)]

Related is bug 886907.  Can we just rm -rf this code?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

ni? to adw for comment 1.

Comment 3

[Marco Bonardo [:mak]]

(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #1)
> Related is bug 886907.  Can we just rm -rf this code?

That bug removes synchronous usage of this db connection, but the connection will stay there to serve asynchronous usage.
What we really want (in addition to bug 886907) is bug 887889, that would make all the I/O async.
And then we should check if it's possible to delay the initialization of the service itself.

Comment 4

[Drew Willcoxon :adw]

(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #1)
> Related is bug 886907.  Can we just rm -rf this code?

Sure.

Comment 5

[Florian Quèze [:florian]]

Here is a first-startup profile where this takes 958ms on the main thread: https://perfht.ml/2sfM8Yt

Comment 6

[Marco Bonardo [:mak]]

I'm not surprised, the service seems to use a transaction to migrate the schema, but not one to create it, see _dbCreate()! And moreover it sets "PRAGMA synchronous = OFF" AFTER doing all these expensive operations...

If we fix bug 886907 then all the APIs are async and should be portable to Sqlite.jsm.

In the meanwhile, a dumb workaround could consist in either setting PRAGMA synchronous = OFF before creating the schema and use the schema version to differentiate an existing file, or just wrap the schema creation in a transaction.

Comment 7

[Florian Quèze [:florian]]

Here is another startup profile where this blocks us for 1617ms: https://perfht.ml/2uCYbfB

Comment 8

[:Gijs (he/him)]

(In reply to Marco Bonardo [::mak] from comment #6)
> I'm not surprised, the service seems to use a transaction to migrate the
> schema, but not one to create it, see _dbCreate()! And moreover it sets
> "PRAGMA synchronous = OFF" AFTER doing all these expensive operations...
> 
> If we fix bug 886907 then all the APIs are async and should be portable to
> Sqlite.jsm.

Hey look, this bug got fixed! How hard would it be to port the APIs to Sqlite.jsm and fix this bug, Marco?


Florian, how bad is this problem in your recent startup profiles? Did this get fixed elsewhere?

(Waiting with setting a priority based on this...)

Comment 9

[Marco Bonardo [:mak]]

This is pretty much waiting for bug 887889, that has some recent activity. Maybe after bug 887889 there's still some small optimizations we can do here.

Comment 10

[Florian Quèze [:florian]]

(In reply to :Gijs from comment #8)

> Florian, how bad is this problem in your recent startup profiles? Did this
> get fixed elsewhere?

Recent startup profiles show this database opened by ContentPrefService2 during FullZoom_init (from browser-fullZoom.js), started during _delayedStartup: https://perfht.ml/2BXYf15

This is after first paint and the current bug summary says "main thread IO before the first window is shown", so I would be OK with closing this bug as WFM.

But it seems Marco has ideas to make this async, which would be much better, so we can morph the bug to that.