Last Comment Bug 599246 - low frame rate while running chrome experiment ball pool with high ball density
: low frame rate while running chrome experiment ball pool with high ball density
Status: RESOLVED WORKSFORME
[chromeexperiments]
: perf
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: general
:
:
Mentors:
http://www.chromeexperiments.com/deta...
Depends on: 595884
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-23 22:33 PDT by Konstantin Novichikhin
Modified: 2013-09-30 14:23 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Konstantin Novichikhin 2010-09-23 22:33:31 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: 4.0b7pre (rev: f5c0015afe0e)

I was running comparison test between chrome and minefield using chrome experiment ball pool. Chrome shows much better performance than minefield with high number of balls.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.chromeexperiments.com/detail/ball-pool/
2. Launch experiment
Actual Results:  
Data gathered using oprofile: http://pastebin.mozilla.org/795754


Build platform
target
i686-pc-linux-gnu

Build tools
Compiler
gcc
Version 
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)     
Compiler flags
-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic -Wno-long-long
-gstabs+ -fno-strict-aliasing -pthread -pipe -DDEBUG -D_DEBUG -DTRACING -g

Compiler
c++ 
Version
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) 
Compiler flags
-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -gstabs+
-fno-strict-aliasing -fshort-wchar -pthread -pipe -DDEBUG -D_DEBUG -DTRACING -g

Configure arguments
--enable-application=browser --enable-debug --disable-optimize
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2010-10-08 22:36:44 PDT
For what it's worth, measuring performance (or profiling) in a debug build is pretty pointless.  It's going to be slow; sometimes very slow, and often in ways totally different from a release build.

In an opt build, this is a tiny bit slower than Chrome for me, maybe.  Hard to tell.

Profile says we spend about:

  40% of our time painting
   7% restyling/reflowing
  24% in mjit-generated code
   7% in js_fun_apply, and an additional 4% in Arguments and CreateThis stub
      calls (see bug 595884).
   4% finalizer thread

and various long-tail stuff.  Should remeasure once bug 595884 is fixed.
Comment 2 Guilherme Lima 2011-12-28 16:21:27 PST
This bug can be closed, I think. The experiment seems very fast for me.

Note You need to log in before you can comment on or make changes to this bug.