User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:126.96.36.199) 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
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.
This bug can be closed, I think. The experiment seems very fast for me.