Last Comment Bug 654705 - TI+JM: v8-richards performance regression
: TI+JM: v8-richards performance regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
-- normal with 3 votes (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: infer-perf-regress
  Show dependency treegraph
Reported: 2011-05-04 07:39 PDT by Jan de Mooij [:jandem]
Modified: 2011-05-22 22:01 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Jan de Mooij [:jandem] 2011-05-04 07:39:37 PDT
Score with -n -m went from 5400 to 4200 points. This is a regression from, bug 649376.
Comment 1 User image Brian Hackett (:bhackett) 2011-05-22 22:01:42 PDT
A couple performance fixes for richards.

Allow generation of native and full call stubs at ICs within inlined frames.  We didn't do this before because of some extra complexity it brings to inline frame expansion (also, before the interpoline this wasn't really possible for native stubs).  Without this, we were taking a slow call at the '' in ',' which really killed perf.  Fixing this brings JM+TI about even with JM+TM.

Constant fold 'x != null' type comparisons where the 'x' cannot be null or undefined.  Previously we stubbed these.  There are a few pretty hot cases of this, in Scheduler.prototype.{queue,release}.

This leaves scores for me at:

d8: 12031
js -m -n: 7375
js -m -j -p: 6460

Will file a separate bug for tracking richards perf improvements, there's still a lot left to do here.  Richards does very little allocation, the gap between engines is due to compiler optimizations and codegen.

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