718481 - Canvas/JS-based C&C game is super slow

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Josh Matthews [:jdm]]

I get low enough framerates on the C&C game at the attached URL that it would be worth profiling to see where the problems are.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I just profiled on Mac for 7 seconds sampling every 100us.  That would give me about 70,000 samples if the CPU were busy the whole time.

I see 22,000 samples in our code and 35,000 samples in kernel code under vm_fault.  Most of this last is under vm_map_lookup_entry.

I wonder what the hell we're doing there....  Or maybe what the script is doing; I see the same sort of lag in Chrome.

Comment 2

[Boris Zbarsky [:bzbarsky]]

If I exclude the kernel time, then our 22,000 samples break down as follows (percentages of the 22,000):

  65% under canvas drawImage
   9% various other canvas ops (getImageData, putImagedata, clearRect, etc)
  10% JS execution
   5% painting
   5% event loop stuff
   4% various audio threads

So my money is on drawImage somehow thrashing the VM subsystem... question is how.  Oh, and note that our actual memory usage is stable.  So we must be allocating and deallocating.

Comment 3

[Boris Zbarsky [:bzbarsky]]

And of course shark no longer does malloc profiling.... :(

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Boris Zbarsky (:bz) from comment #3)
> And of course shark no longer does malloc profiling.... :(

I have a fix for the broken malloc tools on OS X in bug 719427.

Comment 6

[Thomas Ahlblom]

As stated in the duplicated bug 727383 this problem exists in both Windows and Linux as well.

Comment 7

[Dave]

Sorry - if I'd had found that bug i wouldn't have opened bug 727383.
But I guess I'll have to repeat my question from over there:

What's the "right" approach to track such an issue down on Windows?

I've configured my VS2010 to the moz-symbolservers and should be able to attach to firefox.exe...

Comment 9

[Boris Zbarsky [:bzbarsky]]

For what it's worth, note that the Mac and Linux behavior is very different.  In particular, note that on Mac our performance is about the same as Chrome's, while bug 727383 was saying that on Linux Chrome is much faster than us....

Given that the bottleneck on Linux there was _X_, not us, the Linux issue is almost certainly a graphics issue.

Comment 10

[Oleg Romashin (:romaxa)]

I see this page is horribly slow on Linux, with FF and with google chrome, so it is not FF specific issue.