Closed Bug 781145 Opened 12 years ago Closed 12 years ago

IonMonkey: js::GetProperty should have a fast path for string/array length access

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jandem, Assigned: jandem)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ion:p1:fx18])

Attachments

(1 file)

Attached patch PatchSplinter 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();
f();
print(dateNow() - t);
Attachment #650048 - Flags: review?(dvander)
Worth a followup on improving the IC setup?
Attachment #650048 - Flags: review?(dvander) → review+
Whiteboard: [ion:p1:fx18]
https://hg.mozilla.org/projects/ionmonkey/rev/e10b81f123e6

(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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.