Way back in the day, I was told that "Function" casting was faster, and you'll see almost as much of it as "as" casting in the Flex SDK source. I ran a test on my Mac using FP20 standalone and for 5,000,000 iterations "function" casting is only 14ms slower than "as" casting so I'm not sure it really matters what we use for a SWF. I don’t know what testing conditions were in the articles linked in this thread that found a greater difference.
But, IMO, for FlexJS, what really matters is what should happen in the JS output, and the essence of this thread is that in many cases, we can optimize away the call to Language.as. In the past, we always generated the call and you could suppress it with @flexjsignorecoercion, but I'm considering pushing the change where we default to not generating the call and you have to opt-in with @flexjsemitcoercion. But when you opt-in, we do want to cause the same behavior that you will get in a SWF. Right now, "function" casting also results in a Language.as call with a flag that throws an error if "as" fails. I think we can optimize out a lot of these calls as well. Maybe someday, we can get the compiler to do code-flow analysis and determine if we can optimize out these calls to Language.as, but for now, not having these calls makes the code smaller, and reduces some of the dependencies/goog.requires which reduces the likelihood the Closure Compiler will find a circular dependency. -Alex On 1/7/16, 8:30 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: >Interesting side note. As I understand it, try-catch is no longer >expensive >in the case where no error is thrown. I explained to someone why I didn't >want to use a try-catch in some performance critical code, and I cited >Jackson Dunstan's article. They ran the benchmark from the article in a >newer runtime, and the big performance difference was gone. I was able to >confirm on my machine. > >Regardless, I would never wrap a function-style cast in a try-catch. Not >my >style. If I expect it might fail, I check with "is" first, or, sometimes, >use an as-style cast instead and check for null. > >To be honest, my memory of the performance difference between casting >styles is from 6-8 years ago, so my knowledge may be as out of date as the >try-catch thing. Or maybe I'm completely misremembering after so many >years. I've had a few cases where that's true, like the whole toString() >thing the other day. > >- Josh >On Jan 7, 2016 8:07 PM, "Andy Dufilie" <andy.dufi...@gmail.com> wrote: > >> On Thu, Jan 7, 2016 at 10:54 PM, Josh Tynjala <joshtynj...@gmail.com> >> wrote: >> >> > That's odd. I swear I remember someone from Adobe once explaining that >> > function-style casting is faster than as-style casting (with the >> exception >> > of primitive types that have a top level function that makes >> function-style >> > casting impossible, as you mentioned in 1). I've tried to avoid >>as-style >> > casting for years, based on this knowledge. >> > >> > - Josh >> > >> >> See this stack overflow answer and the articles it links: >> http://stackoverflow.com/a/14268394 >> >> *EDIT:* concerning performance, using as is reported to be faster than >>the >> > function call style casting in various articles: [1 >> > <http://jacksondunstan.com/articles/830>] [2 >> > >><http://upshots.org/actionscript/20-tips-to-optimize-your-actionscript>] >> [ >> > 3 >> > < >> >>http://gamedevjuice.wordpress.com/2008/02/15/seven-tips-about-performance >>-optimization-in-actionscript-3/ >> >]. >> > The first article cited looks at the performance differences in depth >>and >> > reports that as is 4x-4.5x faster. >> > >> > *EDIT 2:* Not only is as 4x-4.5x faster in the normal best case, but >>when >> > you wrap the (cast) style conversion in a try-catch block, and an >>error >> > actually ends up being thrown, it's more like 30x - 230x faster. In >>AS3, >> if >> > you think you're going to do something exceptional (in that it could >> throw >> > an error) then it's clear that you should always look before you leap. >> > Never use try/catch unless forced to by the API, and indeed that >>means to >> > never (cast) It also is instructive to look at the performance >> > implications of try/catch even when no exception is thrown. There's a >> > performance penalty to setting up a try/catch block even in the happy >> case >> > that nothing goes wrong. >> > >> > >>