Closed
Bug 603715
Opened 14 years ago
Closed 12 years ago
JM: IC for stricteq
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
People
(Reporter: dmandelin, Unassigned)
References
Details
Spun off from bug 599214 comment 14:
> What about doing this for strict object equality too? V8's earley-boyer calls
> stubs::StrictEq about 1 million times. It's called 500.000 times with both lhs
> and rhs objects.
We have fast paths for the cases where one operand is known to be undefined, null, or boolean, and where both are ints. But there are many dynamic instances of stricteq/strictne on string/string and object/object in earley-boyer, for which we now take a slow call.
I think we want:
- If one operand is of known type, generate a fast path for that type. Support
at least undefined, null, boolean, int, string, and object.
- Otherwise, do it like ==. I think the IC for that starts with an int/int fast
path and generates more as needed.
Comment 1•14 years ago
|
||
typeof x == typeof y && x == y <=> x === y
Hope this helps,
/be
Comment 2•12 years ago
|
||
I suspect this was subsequently done, but anyhow JM was removed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•