On Wed, Aug 14, 2013 at 11:13 AM, <verwa...@chromium.org> wrote: > 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. >
That makes sense. > 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? forEach is used quite a lot. However, I'm not aware of any app being blocked by this. People just change their code to work around the slowness. My goal was to improve performance of this so that there would be less reason for developers to have to refactor their code. > 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/<https://codereview.chromium.org/22545007/> > In the long run I'd rather see us optimize for-of for arrays but that is a far away in the future. -- erik -- -- 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.
