What I mean is that you can't break when you go past the length. You
actually
have to go to a slow path when you read past the length, that does the
entire
in-check; and loops until the index surpasses the preloaded length value.
And
that's independent of whether the receiver is fast-packed or not.
In any case, we don't think this is the right way to optimize this
function. We
rather should first teach crankshaft to inline this function into the
caller,
and then we should teach crankshaft to do the optimizations you are doing by
hand; to ensure that all such JavaScript code benefits from that
optimization.
Do you have a particular pressing need for this function to become fast? In
other words, is there a real-world application that is currently blocked by
this, performance-wise? If not, we'd rather focus on doing what we described
above, rather than adding more localized (potentially buggy) optimizations
that
we'll have to throw out again later.
https://codereview.chromium.org/22545007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
