Last Comment Bug 781145 - IonMonkey: js::GetProperty should have a fast path for string/array length access
: IonMonkey: js::GetProperty should have a fast path for string/array length ac...
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
-- normal (vote)
: ---
Assigned To: Jan de Mooij [:jandem]
: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: IonSpeed
  Show dependency treegraph
Reported: 2012-08-08 05:37 PDT by Jan de Mooij [:jandem]
Modified: 2012-08-09 06:16 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (3.77 KB, patch)
2012-08-08 05:37 PDT, Jan de Mooij [:jandem]
dvander: review+
Details | Diff | Splinter Review

Description User image Jan de Mooij [:jandem] 2012-08-08 05:37:45 PDT
Created attachment 650048 [details] [diff] [review]

GetPropertyOperation has a fast path for JSOP_LENGTH. This is important for strings because apparently it avoids creating lots of string objects. This patch factors it out and also calls it from js::GetProperty.

Numbers for the micro-benchmark below:

JM+TI (--no-ion) :  2 ms
Ion (new)        : 13 ms
Ion (old)        : 79 ms

JM+TI is still much faster because its IC can handle the mixed object/string case, while Ion only uses an IC if the value is definitely an object. The attached patch is pretty straight-forward though and is a tiny date-format-xparb win.

function f() {
    var x = new String("foo");
    var res = 0;
    for (var i=0; i<1000000; i++) {
        res += x.length;
        x = "foo";
    return res;

var t = dateNow();
print(dateNow() - t);
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2012-08-08 09:46:48 PDT
Worth a followup on improving the IC setup?
Comment 2 User image Jan de Mooij [:jandem] 2012-08-09 06:16:11 PDT

(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #1)
> Worth a followup on improving the IC setup?

Fixing it wouldn't be noticeable on date-format-xparb, and I doubt this mixed object/string case is common in performance-critical code. So I'm inclined to wait until we know it really is a problem we have to fix.

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