Bug 95450 – [Qt][WK2] REGRESSION(r127091): It made layout tests extremely slow

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[Csaba Osztrogonác]

runtime on x86-64 Linux Qt Release WebKit2 (Amazon EC2):
- before this patch: 15 mins, 18 secs - http://build.webkit.sed.hu/builders/x86-64%20Linux%20Qt%20Release%20WebKit2%20%28Amazon%20EC2%29/builds/8144
- after this patch: 37 mins, 56 secs - http://build.webkit.sed.hu/builders/x86-64%20Linux%20Qt%20Release%20WebKit2%20%28Amazon%20EC2%29/builds/8145

runtime on x86-32 Linux Qt Release WebKit2  bot:
- before this patch: 22 mins, 59 secs - http://build.webkit.sed.hu/builders/x86-32%20Linux%20Qt%20Release%20WebKit2/builds/28318
- after this patch: 4 hrs, 58 mins, 29 secs - http://build.webkit.sed.hu/builders/x86-32%20Linux%20Qt%20Release%20WebKit2/builds/28319

Could you check what happened?

[Luciano Wolf]

I'm investigating it: I suspect that some cache cleanup is happening between each test slowing down the whole test suite.

[Csaba Osztrogonác]

Simon, what do you think, is it possible if it is related 
somehow to your similar JSC slowdown thing?

( https://trac.webkit.org/changeset/127091 made WK2 tests very slow. )

[Luciano Wolf]

If the initialization/destruction of cache directories couldn't be avoided (even when tests doesn't have a manifest asking for appcache) and it causes this long delay we could turn it on only when needed. We could disable it at: 

Tools/WebKitTestRunner/TestController.cpp:
...
bool TestController::resetStateToConsistentValues() {
   ...
   WKPreferencesSetOfflineWebApplicationCacheEnabled(preferences, false);
   ...
}

and modify appcache related tests to use the same function as LayoutTests/http/tests/appcache/disabled.html uses, but setting it as true:

testRunner.overridePreference("WebKitOfflineWebApplicationCacheEnabled", true);


I'm a bit worried because it will affect all ports. GTK seems to take ~30min to run layouttests for WK2, but I don't know how powerful are their test machines. Otherwise could be another platform getting some benefit from this modification (as we were taking ~15min to run the tests).

[Luciano Wolf]

(In reply to comment #3)

The last proposal doesn't work at all. I'm investigating another interesting path with setanta. When you run appcache tests you get new data to be written on your cache directory. If you clean it (right now we're doing a good & old "rm -rf")before running tests that doesn't use appcache they will run faster as before. So it seems a matter of wiping out all cache data before running other test.

[Csaba Osztrogonác]

I skipped http/tests/appcache tests again until proper fix, because
2x- 12x longer testing time for several test unacceptable -
https://trac.webkit.org/changeset/127257

[Simon Hausmann]

(In reply to comment #2)
> Simon, what do you think, is it possible if it is related 
> somehow to your similar JSC slowdown thing?

As much as I'd like to, I'm don't think it is related. But 2x-12x is quite drastic. 

Luciano, I suggest to start the http manually (there's a script for that in Tools/Scripts) and then valgrind --tool=callgrind DRT /path/to/a/single/appcache test to see if anything shows up.

[Luciano Wolf]

It seems to be related to SQL database + Mutex usage. In the function:

int SQLiteStatement::prepare() (/Source/WebCore/platform/SQLiteStatement.cpp) 

there is a sqlite3Handle() to get back a sqlite3 object:

error = sqlite3_prepare16_v2(m_database.sqlite3Handle(), m_query.charactersWithNullTermination(), -1, &m_statement, &tail);

If I return a "0" from sqlite3Handle() the tests run faster as before. I'm managing to compile a GTK version to be able to compare testing timings.

[Luciano Wolf]

GTK tests also face the same speed reduction. So fixing this issue could provide a speed boost in other platforms too.

[Zan Dobersek]

This problem reminds me of bug #70699.

(In reply to comment #8)
> GTK tests also face the same speed reduction. So fixing this issue could provide a speed boost in other platforms too.

The GTK 64-bit WK2 bot is underpowered, plus the tests are at the moment badly gardened for that platform. Still, the tests in http/tests/appcache are fast enough:
http://test-results.appspot.com/dashboards/treemap.html#group=%40ToT%20-%20webkit.org&treemapfocus=LayoutTests%2Fhttp%2Ftests%2Fappcache&builder=GTK%20Linux%2064-bit%20Release%20WK2%20(Tests)

[Luciano Wolf]

I've tried this GTK approach but the problem persists. The ApplicationCache.db file is created as soon as we have http/tests/appcache tests running. From this point (appcache tests run at the very beginning of test suite) the ApplicationCache.db will be there until all the tests are processed slowing them all. I think the cache directory should be something temporary that could be erased between each test. This is not possible nowadays because we can have multiple tests running simultaneously. Each test should have it's own temporary path. As it is pointed in the link for bug#70699 the proper solution could came after we have a function to set cache patch implemented in WebKitWebContext. Also removing myself from "Assigned To:".

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.