Bug 61239 - Unbearably slow performance on MinGW-w64
Summary: Unbearably slow performance on MinGW-w64
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-21 02:43 PDT by Jonathan Liu
Modified: 2019-05-02 16:18 PDT (History)
1 user (show)

See Also:


Attachments
JavaScript stopwatch test (1.09 KB, application/xhtml+xml)
2011-05-23 04:33 PDT, Jonathan Liu
no flags Details
proposed patch (1.37 KB, patch)
2011-12-10 21:34 PST, Jonathan Liu
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Liu 2011-05-21 02:43:54 PDT
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/.
Comment 1 Jonathan Liu 2011-05-23 03:32:16 PDT
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).
Comment 2 Jonathan Liu 2011-05-23 03:44:12 PDT
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.
Comment 3 Jonathan Liu 2011-05-23 03:49:47 PDT
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.
Comment 4 Jonathan Liu 2011-05-23 03:50:49 PDT
Perhaps this performance problem is timer-related?
Comment 5 Jonathan Liu 2011-05-23 04:33:10 PDT
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.
Comment 6 Jonathan Liu 2011-05-25 05:11:12 PDT
It seems that SharedTimerQt::timerEvent isn't firing as often as it should for some reason...
Comment 7 Jonathan Liu 2011-12-10 19:22:04 PST
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.
Comment 8 Jonathan Liu 2011-12-10 20:21:36 PST
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.
Comment 9 Jonathan Liu 2011-12-10 21:34:16 PST
Created attachment 118704 [details]
proposed patch
Comment 10 Jonathan Liu 2011-12-13 05:58:14 PST
This is a problem with the CRT headers provided by the compiler and not with WebKit.
Comment 11 Alexey Proskuryakov 2011-12-13 09:09:19 PST
Comment on attachment 118704 [details]
proposed patch

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