332545 - Poor performance on game in URL field

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Current trunk Linux build

HARDWARE: P3-733 CPU, 768 MB RAM

STEPS TO REPRODUCE:
1)  Load URL in URL field.
2)  Click the "LICK HERE TO LAUNCH GAME" button.
3)  When the game initializes and says "Click to start", read the instructions
    and then click to start.
4)  Play for 3-4 minutes.

ACTUAL RESULTS:  Game is very jerky, cpu is pegged, game clearly lags.

EXPECTED RESULTS:  Be faster, if possible!

NOTE:  I realize that this may be a problem with the game itself or with my slow computer.

Profile is coming up, along with a bit of analysis; we should probably file separate bugs on the separate issues if they seem to merit it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile

Some quick analysis of the profile (not all percentages below are exclusive, but I tried to make them as exclusive as I can):

1)  6.6% of total time is spent in (not under!) js_LookupPropertyWithFlags.  If
    I look at time under js_LookupPropertyWithFlags, that's 38% of total time.
  1a)  4.1% of total time is spent in JS_SearchScope (called from
       js_LookupPropertyWithFlags, basically).
  1b)  6.8% of total time is spent in JS_DHashTableOperate; almost all calls
       come from js_StartResolving and js_StopResolving.

2)  6.3% of total time is spent in (not under) ".L824" which is only called by
    js_Invoke and js_Execute.

3)  8.4% of total time is spent under (not in) XPCWrappedNative::CallMethod
    (this is us calling from JS into Gecko, basically).  Actual time spent in
    Gecko at this point (basically twiddling style rules and posting events) is
    5.5% of total time; the rest is in XPconnect and security manager.

4)  1.8% of total time is spent handling restyle events (reresolving, etc).

5)  0.9% of total time is spent reflowing.

6)  6.7% of total time is spent under nsLayoutUtils::GetFrameForPoint (click
    event targeting, basically).

7)  7.5% of total time is spent painting (that includes both display list
    construction and actual painting; the latter is about 4.9% of total time,
    with about half of the painting being image painting and the rest being
    painting somewhere out in XUL(!)).

My conclusions:

A)  "Gecko" time (reflow, style system, painting, event targeting, etc) adds up
    to about 23% of the total time here.
B)  JS property resolution seems to be 38% of total time (and the XPConnect part 
    of it seems to be no more than 2% of total [5% of resolution], while
    js_LookupHiddenProperty figures rather prominently [50% of resolution is
    under it, though it resolves recursively, so the numbers are hard to pin
    down]).
C)  Other JS engine code is at least 6% of total time.

At the very least, the time spent in property resolution seems really high... It's possible that the painting and GetFrameForPoint times are a little high too.

Does anything else jump out at anyone?  Should I file spinoff bugs on property resolution and painting and event targeting here?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 217000 [details]
Profile

For ease of profile browsing:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=217000!/jprof.html

Comment 3

[Brent Silby]

The problem is not in the game. It runs well in IE on Windows, and Firefox 1.5 on Windows seems fine (perhaps a little slow). I have noticed that most of my dhtml games are laggy in the Linux builds.

Comment 4

[Gregory Pappas [:gregp]]

Runs great now!