Bug 61239 – Unbearably slow performance on MinGW-w64

• Component: New Bugs
• Status: RESOLVED INVALID

[Jonathan Liu]

If you compile QtWebKit (either part of Qt 4.7.3 or QtWebKit 2.2 branch) with MinGW-w64, performance is really slow.
Acid 3 test takes a long time to run.
If you middle-click to switch to auto-scroll, it takes 1 second for the mouse cursor to change.
If you move mouse up or down when auto-scroll is enabled, the page scrolls with a delay of 1 second. It updates, pauses for a second, updates, pauses for a second, updates, etc.
JavaScript animations are really slow (e.g. http://jquery.malsup.com/cycle/).

Performance is fine on MinGW GCC 4.4.0 (32-bit).
MinGW-w64 compiler is MinGW-w64 GCC 4.5.2 tdm64-1 from http://tdm-gcc.tdragon.net/.

[Jonathan Liu]

This issue also occurs in QtWebKit included with every version of Qt i've tested with MinGW-w64 (Qt 4.7.0 beta 2 up until Qt 4.7.3).

[Jonathan Liu]

To check whether this occurs in Qt, specify / as a command line argument to one of the examples (e.g. browser.exe / or fancybrowser.exe /). Then you can navigate to http://acid3.acidtests.org/ or http://jquery.malsup.com/cycle/ to check performance and try auto-scroll with middle-click. The / argument is to avoid the example programs crashing on startup if JIT is enabled.

The patch from https://bugs.webkit.org/show_bug.cgi?id=61235 to disable JIT can be used to avoid crashing on startup if using QtWebKit 2.2 branch. The performance problem still remains though.

This performance problem seems to occur regardless of whether JIT is enabled or disabled.

[Jonathan Liu]

This problem also occurs in Qt Assistant which uses QtWebKit. If you middle-click and auto-scroll you will notice the 1 second lag as the page scrolls.

[Jonathan Liu]

Perhaps this performance problem is timer-related?

[Jonathan Liu]

Created attachment 94398 [details]
JavaScript stopwatch test

This demonstrates 1 second performance lag when using JavaScript. If you open it in QtTestBrowser after compiling QtWebKit or a Qt WebKit browser example and click Start, you will notice a 1 second (exactly 1000ms for me) delay between stopwatch updates. The behaviour of this seems to also correspondly directly to how the auto-scroll lags.

[Jonathan Liu]

It seems that SharedTimerQt::timerEvent isn't firing as often as it should for some reason...

[Jonathan Liu]

Seems to be a problem related to the Windows implementation of wtf::currentTime(). Modifying wtf::currentTime() to return double(QDateTime::currentMSecsSinceEpoch()) / 1000.0 solves the problem for me.

[Jonathan Liu]

I've located the cause of the problem. The _ftime function on MinGW-w64 seems to always return a time buffer with millitm field set to 0. This only occurs when compiling with 64-bit. The problem does not occur with MinGW 32-bit or MinGW-w64 32-bit (-m32).

A workaround for the problem would be to use struct __timeb64 and _ftime64 instead of struct _timeb and _ftime in the static lowResUTCTime() function in JavaScriptCore/wtf/CurrentTime.cpp.

[Jonathan Liu]

Created attachment 118704 [details]
proposed patch

[Jonathan Liu]

This is a problem with the CRT headers provided by the compiler and not with WebKit.

[Alexey Proskuryakov]

Comment on attachment 118704 [details]
proposed patch

Clearing review flags, since the reporter marked the bug INVALID.