The default bug view has changed. See this FAQ.

Make obj->getElement actually call into the ops getElement hooks

RESOLVED FIXED in mozilla10

Status

()

Core
JavaScript Engine
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

9 Branch
mozilla10
x86
Mac OS X
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Should help with arrays of various sorts.
Created attachment 571849 [details] [diff] [review]
Call the class getElement hook from JSObject::getElement as needed.
Attachment #571849 - Flags: review?(jwalden+bmo)
(In reply to Boris Zbarsky (:bz) from comment #0)
> Should help with arrays of various sorts.

Help what? That's a pretty terse description. ;-) Is this just a bug in the way we use ops?
Comment on attachment 571849 [details] [diff] [review]
Call the class getElement hook from JSObject::getElement as needed.

Review of attachment 571849 [details] [diff] [review]:
-----------------------------------------------------------------

Did I really write that, and forget to start calling the getElement op?

Anybody need some fresh egg?  Slightly-used, but still fresh?
Attachment #571849 - Flags: review?(jwalden+bmo) → review+
> Help what?

Performance, sorry.  Instead of converting uint32 to jsid and then calling the jsid ops and then checking to see whether the jsid is an int and branching on that, etc, this patch just directly calls the op taking a uint32, which arraylikes tend to fast-path.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ce40bde00ef8
Flags: in-testsuite-
Priority: -- → P2
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/ce40bde00ef8
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.