The default bug view has changed. See this FAQ.

low frame rate while running chrome experiment ball pool with high ball density

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
7 years ago
4 years ago

People

(Reporter: Konstantin Novichikhin, Unassigned)

Tracking

({perf})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [chromeexperiments] , URL)

(Reporter)

Description

7 years ago
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
(Reporter)

Updated

7 years ago
Keywords: perf
Whiteboard: [chromeexperiments]
Version: unspecified → Trunk
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.
Depends on: 595884

Updated

6 years ago

Comment 2

5 years ago
This bug can be closed, I think. The experiment seems very fast for me.

Updated

4 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.