669206 - performance issue on webgl with firefox

Status: RESOLVED DUPLICATE of bug 1010527

(Core :: Graphics: CanvasWebGL, defect)

Description

[Cedric Pinson]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/11.04 Chromium/14.0.803.0 Chrome/14.0.803.0 Safari/535.1

Steps to reproduce:

I run the example here http://plopbyte.com/demojs-fff/


Actual results:

It runs slower than on chromium 14 under linux


Expected results:

run the same

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Runs fast here (Linux 64bit, NVIDIA), but anyway, here's what perf says.

# launch firefox
$ ps aux | grep firefox   # get firefox PID
# now launch your demo
$ perf record -f -g -p THE_PID_OF_FIREFOX
# wait a few seconds, then Ctrl-C to stop recording
$ perf report --sort dso

+     28.67%  [kernel.kallsyms]
+     24.03%  libxul.so 
+     16.62%  libnvidia-glcore.so.270.41.19
+     11.21%  libGL.so.270.41.19 
+      5.61%  [unknown] 
+      2.81%  libpthread-2.13.so 
+      2.76%  libasound.so.2.0.0  
+      2.02%  libc-2.13.so

The [kernel.kallsyms] seems to be mostly about threads waiting for locks. The libxul.so is mostly about audio streams stuff, and some JS engine stuff. The nvidia/GL part is mostly opaque, I can't get much info about it. The [unknown] is mJITted javascript: perf says it's called by JaegerShot. The libpthread and libasound parts further confirm that a lot of time is spent loading and decoding <audio> elements.

The WebGL implementation code itself doesn't account for a large part of the time spent here.

Pretty confident that what you're experiencing here is bug 592833.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

If you're interested, you could try removing the <audio> part of your demo to see how much faster it runs.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

There's only 1 audio element running in that page, so reducing the thread count isn't going to make a huge amount of difference to the performance of that page. Benoit, can you post a more detailed perf report?

If the decode/audio threads are waking up too much that could affect performance, but that's not bug 592833, that's a separate issue.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: perf data file

here's the perf data file, uncompress and run `perf report` in the same directory.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: perf graph as plain text file (xz-compressed)

Uncompress with xz, this is a plain text file with a call graph. It suggests that quite some time is spent around vorbis decoding.

This was generateed from the perf.data file by:

$ perf report -g

let me know if you want a different view.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

Note: all this was recorded in the middle of running the demo, this doesn't include the initial loading.