Closed Bug 1271141 Opened 6 years ago Closed 6 years ago

WPT tests incurring gigabytes of I/O in Places SQLite database


(Testing :: web-platform-tests, defect)

Version 3
Not set


(Not tracked)



(Reporter: gps, Unassigned)


(Blocks 1 open bug)


Same deal as bug 1271035. It's happening in WPT tests too.


                   Bytes Written
Linux64 Opt W1     1,745,862,656
Linux64 Opt W3     1,115,738,112
Linux64 Opt W4     1,557,487,616
Linux64 Opt W5     1,065,558,016
OS X 10.10 Opt W1  1,960,006,144
OS X 10.10 Opt W3  1,448,801,792
OS X 10.10 Opt W4  1,802,521,600
OS X 10.10 Opt W5  1,257,460,736

This is *system* bytes during the entire job. A few hundred MB will be e.g. extracting the binary and test archive. And, not all I/O incurred by SQLite hits the system (a lot gets serviced by the page cache). From local running with procmon, Places seems to be the source of most of the I/O during test execution however. The magnitude of the problem appears smaller, but it's definitely there.

I know WPT tests are a bit higher level than reftests. And I /think/ there are e.g. DOM features that may rely on Places working to pass. What I don't know is if WPT tests any of those.

Ms2ger: What are the concerns with disabling Places when running WPT? If some tests require Places, could we somehow annotate tests that require Places and enable Places only for those?
Flags: needinfo?(Ms2ger)
Blocks: fastci
I presume that tests requiring e.g. history.back will not work without places enabled. So just disabling it isn't going to work. Working out where it's safe to disable now is straightforward; we do a try run with it disabled and see where tests fail. The more challenging problem is keeping that information correct as we sync from upstream.
Flags: needinfo?(Ms2ger)
(In reply to James Graham [:jgraham] from comment #1)
> I presume that tests requiring e.g. history.back will not work without
> places enabled.

session history is different from global history and doesn't depend on Places. It should work.
Try seems to agree with you:

I'll do a bigger try run to check there isn't any platform-specific weirdness, but otherwise this looks good.

(if we think this is the right default for testsuites, it might make sense to edit prefs_general.js to set this pref, and then unset it for test[suites] where it is not wanted).
This landed as part of Bug 1273176
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.