Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090212 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090212020259 With JIT enabled I only get half the points by running the Google V9 Benchmark Suite as with JIT disabled. That is reproducible on OS X and Windows. Here some numbers: JIT enabled JIT disabled Firefox 3.0.6 - 173 Firefox 3.1b3pre 116 199 Firefox 3.2a1pre 104 195 I don't know how specific this tests are and how often users will be affected by their daily browsing but with jit enabled by default, we should take care of this for Firefox 3.1.
Can someone figure out P1/P2 for this? We basically need to sit down, find out where and why we don't trace, and then clean up whatever happens. This will need upvar and a few other perf regression fixes I am working on at least. Possibly some smaller stuff as well. If we try to trace inside loops but keep failing or trace the innermost loop but fail around it, performance can tank substantially.
It looks like that it is a regression since b2 was released. Running the test with JIT enabled gives me 166 points with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081201 Minefield/3.1b3pre ID:20081201020244
Keywords: regression, regressionwindow-wanted
Builds before b1 fail on the first test, so we don't get an overall result for the benchmark. Shortly after that date we had a good performance but are still slower as JIT disabled. Then it went down step by step. Here some results from tests on 1.9.1 with JIT enabled and 3 runs: Build ID result 08110502 186 08111002 170 08111502 165 08120102 162 09010302 162 09010902 135 09020502 115
I don't think we can block on this, since we don't know what we'd be committing to fixing. As Andreas says, we need to identify why we're not tracing through their benchmarks, and then file bugs on those issues. If we believe that tracing at those points is necessary, then those things should become blockers.
Flags: blocking1.9.1? → blocking1.9.1-
This is most definitively not a single issue that can be fixed but a series of fixes. As an example, see https://bugzilla.mozilla.org/show_bug.cgi?id=458016 and the 3 dependent bugs I forked off to make it fast.
The results for the Google V8 benchmark look similar to what has been reported in bug 460050. Can we expect an enhancement when bug 452498 gets fixed?
In the todays German biggest computer magazine an article (http://www.heise.de/ct/inhalt/2009/14/44/) compares the different benchmark tests between IE8, Opera 10Beta, Chrome2, Safari 4 and our 3.5 Preview version. Especially for the V8 benchmark suite we don't have a satisfying result: IE8 92 Opera 10Beta 212 Firefox 3.5 Preview 354 Chrome 2 2702 Safari 4 2066 Even it cannot be fully compared to real world websites those benchmarks have an influence to users.
I'm not sure what your point is in comment 7, whimboo. Nobody is saying that we shouldn't fix this, and indeed people are working on improving our performance on the lisp-translated-to-JS and lambda-regexp-specific stuff that manifests here. If you know of bugs that will affect this, please do add them as deps!
I only wanted to point to a press article. Nothing more. I don't have any knowledge in this area but when I read about something I will make sure that those bugs will be added.
I think this bug can be resolved fixed. Just TM is about 4x faster than interpreter. TM+JM+profiling is about 7.5x times.
Absolutely! Compared to my numbers in comment 0 we made an insane jump to 3118 points on the same machine.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.