Bug 16448 - [GTK] Celtic Kane JavaScript performance on Array test is slow relative to Mac
Summary: [GTK] Celtic Kane JavaScript performance on Array test is slow relative to Mac
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Mark Rowe (bdash)
URL:
Keywords: Gtk, Performance
Depends on:
Blocks:
 
Reported: 2007-12-15 03:47 PST by Alp Toker
Modified: 2007-12-16 17:15 PST (History)
1 user (show)

See Also:


Attachments
Patch (6.11 KB, patch)
2007-12-16 14:34 PST, Mark Rowe (bdash)
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alp Toker 2007-12-15 03:47:25 PST
The GTK+ port takes an unexpectedly high time on the Celtic Kane "Array object" benchmark:

  http://celtickane.com/webdesign/jsspeed2007.php

wk 605ms
fx2 264ms

the DOM test is also suspiciously slow:

wk 261ms
fx2 179ms

Probably something silly going on. We need to throw a profiler at this.
Comment 1 Mark Rowe (bdash) 2007-12-15 08:18:17 PST
Grr, I spent a little while this evening trying to find a profiler on Linux that would give me understandable data but failed miserably.
Comment 2 Mark Rowe (bdash) 2007-12-16 02:50:06 PST
Finally got gprof working.  Most of the time looks to be spent inside toString in the comparison function below ArrayInstance::sort.  I have a patch locally that tweaks ArrayInstance::sort to call toString O(N) times rather than O(N log N) times, which drop the Array test from 158 to 7ms on my Linux machine.  I'm not entirely sure *why* toString was proving more expensive on Linux as gprof output isn't proving very enlightening. The patch is also a win on Mac (36 -> 6ms on Array).
Comment 3 Mark Rowe (bdash) 2007-12-16 14:19:42 PST
I'm not seeing the DOM test as being slow on my machine.  It consistently takes around 25ms.
Comment 4 Mark Rowe (bdash) 2007-12-16 14:21:22 PST
I'm re-titling this bug for now to cover the Array aspect for which I have a patch.  We should file separate bugs on other parts of the benchmark that are slower than expected.
Comment 5 Mark Rowe (bdash) 2007-12-16 14:34:46 PST
Created attachment 17939 [details]
Patch
Comment 6 Maciej Stachowiak 2007-12-16 14:59:15 PST
Comment on attachment 17939 [details]
Patch

r=me
Comment 7 Maciej Stachowiak 2007-12-16 14:59:32 PST
(But I suggested an improvement to the comment)
Comment 8 Mark Rowe (bdash) 2007-12-16 17:15:09 PST
Landed in r28782.