That's a good call, Andy. You're absolutely right that a for-each loop could also have its own return statements that are meant for the surrounding function. With that in mind, I don't think there's a special case here that the compiler can easily detect to optimize. It sounds like you should simply avoid for-each on Arrays in performance critical code. If you're using for-each in existing code, and it seems too slow, you'll need to manually optimize using one of the alternate approaches we've discovered here.
- Josh On Mon, May 9, 2016 at 1:02 PM, Andy Dufilie <andy.dufi...@gmail.com> wrote: > There can also be return statements within loops as well as "break to > label" or "continue to label". It all seems very messy to me and I still > think it should be behind an optimization option. The current > implementation works perfectly and I would prefer the JS output to be > minimally different from the AS input, which makes debugging easier. > > Array.isArray() is the correct way to test if something is an Array, btw. > > On Mon, May 9, 2016 at 1:12 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 5/9/16, 9:37 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > > > >We might be able to figure out how to use Array.some() instead. Return > > >false for most iterations of the loop, and then return true when a > "break" > > >is encountered (and return false when "continue" is encountered). > > >Replacing break and continue could be tricky, though, since they are > > >handled in a different sub-emitter. > > > > Possible. Testing needs to be done to make sure that these patterns > > perform better since they introduce a function call and maybe some > scoping > > issues. > > > > It may also be that some future version of the compiler generates > > different patterns if it knows there is no early exit from the loop. > > > > -Alex > > > > >
