Closed
Bug 824522
Opened 12 years ago
Closed 12 years ago
ion::GetNameCache ends up resolving things over and over again on the Window object
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla22
People
(Reporter: bzbarsky, Assigned: jandem)
References
Details
Consider this testcase:
<script>
var count = 100000;
var start = new Date;
for (var i = 0; i < count; ++i)
performance;
var end = new Date;
document.write((end - start) / count * 1e6);
</script>
This ends up taking about 1us per loop iteration because ion::GetNameCache keeps calling the resolve hook on the Window... I guess the basic worry here is that we find the property on the proto but later the resolve hook can find it on the window itself? The problem is that this resolve hook promises to never do such things: it doesn't ever start shadowing proto properties (similar to a ListBase).
Is there any sane way we can teach ion about this special case? Maybe it could assume sane behavior out of the resolve hook for dom globals? Long-term (maybe weeks to months) I'm working on removing the resolve hook from Window, but if it's easy to hack around this in the meantime it might be worth it...
Hrm, that's weird. If we find it on the proto we should be guarding on the shape of the window (or something). Is the IC failing to compile anything at all?
![]() |
Reporter | |
Comment 2•12 years ago
|
||
I don't know. How do I check?
Note that the window has a non-null resolve hook, in case it matters...
Following up from IRC, the problem is that ion::GetNameCache immediately bails out if it finds the property on the prototype chain.
![]() |
Reporter | |
Comment 4•12 years ago
|
||
This is being reported as a recurring problem; see bug 860980. Anything we can do to get movement on this?
![]() |
Reporter | |
Comment 5•12 years ago
|
||
Eric, if you get a chance, could you look?
Flags: needinfo?(efaustbmo)
![]() |
Reporter | |
Comment 6•12 years ago
|
||
Looks like this is actually fixed-enough as filed, by three things:
1) Bug 851109 made us actually IC this in ion, dropping the average time from 1000ns to
200ns for me. This is the real fix for this bug.
2) The landing of the baseline compiler improved the time to 140ns (probably by running
more of the testcase in ion, due to the lower threshold).
3) Something in the http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=70e0955ccc87&tochange=b35170667a2f range. No idea what.
Going to mark this fixed. There's a remaining issue here for slotful props on the global's proto that Eric filed bug 918593 on.
Updated•12 years ago
|
Assignee: general → jdemooij
Target Milestone: --- → mozilla22
You need to log in
before you can comment on or make changes to this bug.
Description
•