Right now we take a 2-3% hit on untraced interpreted code
I have added the quick-cache shaver suggested but it doesn't seem to help much. Eventually all such loops should be compiled, so the overhead should be irrelevant (in theory).
I suggest downgrading this to wanted. Overhead seems to be down to a point where I can't reliably measure it. Its probably still 2%-ish but our timer resultion is 5% so it goes up and down and sideways. Bump up to blocker if you feel this needs further improvement. Keep in mind that ideally all loops affected by this slowdown should be traced (eventually).
Summary of discussion with Brendan: 2% penalty only appears for tight loops, which are supposed to be traced anyway. The overhead is dwarfed for loops we can't trace (i.e. DOM calls). In other words, this should be a non-issue eventually. Currently it does hurt on a few SS cases (i.e. recursive code, since we don't speed it up but take the penalty). However, for such code the much bigger cost is attempting to trace and failing to do so. So the proper fix is to make all important loops traceable, not fiddling with the branch monitoring penalty. Closing the bug.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.