Summary: | Unbearably slow performance on MinGW-w64 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Jonathan Liu <net147> | ||||||
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED INVALID | ||||||||
Severity: | Normal | CC: | arkr17997 | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 7 | ||||||||
Attachments: |
|
Description
Jonathan Liu
2011-05-21 02:43:54 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). 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. 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. Perhaps this performance problem is timer-related? 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.
It seems that SharedTimerQt::timerEvent isn't firing as often as it should for some reason... 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. 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. Created attachment 118704 [details]
proposed patch
This is a problem with the CRT headers provided by the compiler and not with WebKit. Comment on attachment 118704 [details]
proposed patch
Clearing review flags, since the reporter marked the bug INVALID.
|