If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Need fast paths (ICs?) for indexed access on DOM lists

NEW
Unassigned

Status

()

Core
JavaScript Engine
4 years ago
2 years ago

People

(Reporter: bz, Unassigned)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 806238 [details]
Testcase

On the attached testcase, only 30% of the time is under the DOM proxy handler's get(), and only 50% is under Proxy::get().

If we had faster paths here we could use them for a self-hosted array_slice too, perhaps.

Comment 1

4 years ago
Is this op/s or time taken to complete?

My results are
Nightly: 77
Chrome 33: 93
IE 11: 386
The output of the testcase is nanoseconds per operation being tested.
And just for comparison, you should replace "l[j]" in the testcase with "l.item(j)", which is supposed to do more or less the same thing, to see how fast the code _could_ go in theory if this bug were fixed.

Comment 4

4 years ago
(In reply to Boris Zbarsky [:bz] (reviews will be slow; ask someone else) from comment #3)
> And just for comparison, you should replace "l[j]" in the testcase with
> "l.item(j)", which is supposed to do more or less the same thing, to see how
> fast the code _could_ go in theory if this bug were fixed.

Then I get:

Nightly - 50
Chrome doesn't seem to like your idea - 2600
IE 11 - 327
Interesting.  For me, Chrome (a 35 dev channel) build shows about the same number with both l.item(j) and l[j]...
(Assignee)

Updated

3 years ago
Assignee: general → nobody
Blocks: 1105621

Comment 6

3 years ago
Browser: l[j] / l.item(j)
Chrome 39: 99 / 87
Firefox 34: 81 / 36

The difference got bigger in the last 9 months.
Blocks: 1218972
You need to log in before you can comment on or make changes to this bug.