I ran it multiple times on multiple browsers and I did not see a repeatable pattern. The different comparisons were sometimes faster but on the next run, the faster one might have been slower.
No matter what pattern is used, there’s no significant difference. The only thing that was constant was that Chrome was roughly twice as fast as Firefox and the Flash version took about 3 times as long in Chrome. I did not bother testing the Flash version in Firefox because I have the debug Flash plugin installed there. Harbs > On Jun 29, 2017, at 10:23 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Now that the release is out, I spent some more time looking into the issue > of what variables should be initialized and thus, how we should handle > equality testing (==, ===, etc). My conclusion remains the same: there > is no one right answer. But I saw some interesting things. > > I started with the test case in > https://issues.apache.org/jira/browse/FLEX-35330 and added to it. I was > concerned that the test case loop performance could be skewed by runtime > loop optimizations. Our code doesn't have many long loops. Our equality > testing is scattered throughout the code as objects are instantiated and > user interaction causes changes. And also note, one of the points of > beads and PAYG is to reduce the number of equality tests in the final > output. IOW, if your app isn't going down both code paths of an if > statement, then a lightweight bead could eliminate that test. > > So, I wanted to make sure any runtime code flow would think that the loop > variables might change so they don't extract it to a constant outside of > the loop. I decided to use the Date() class and its getFullYear() as the > thing that might change but doesn't. You can see the newer test by > downloading Main.mxml > http://home.apache.org/~aharui/FlexJS/FLEX35330/src/Main.mxml > > The "work" in the loop now looks more like: > var obj:Object; > var now:Date = new Date(); > if (now.getFullYear() < 2016) > obj = {}; // should never get here, but flow analysis shouldn't > know that > return (obj != null) ? Math.random() : 0; > > > The JS version of the test is here: > http://home.apache.org/~aharui/FlexJS/FLEX35330/bin/js-release/ > The SWF version of the test is here: > http://home.apache.org/~aharui/FlexJS/FLEX35330/bin-debug/ > > For me, the SWF version is considerably slower. The JS version can run a > test in 200ms that takes Flash 12000ms! > > But more interestingly, this version of the test also checks the code > pattern: > > if (someObject) > > And for me, on both SWF and JS, I'm seeing that run as fast or faster for > "boolean" as using strict equality: > > if (someObject === true) > > Do others see that? Because if that's true (and it isn't a bug in the > test), given that "if (someObject)" doesn't require boolean variable > initialization and is smaller code on both platforms, it seems like that > would be a pattern the compiler should support and would get my vote as > the default pattern. > > We certainly want to support those that want to use strict equality in > places where "*' isn't used, but in this test, the difference is > negligible. Google Closure Compiler isn't currently smart about member > variable initialization so each initialized variable adds a few bytes to > the minified JS. It might GZIP out. I didn't try that yet. > > Google's optimizer/minifier is pretty aggressive about code rewriting. > The snippet above ends up looking something like: > var a=null;2016>(new Date).getFullYear()&&(a={});return > null!=a?Math.random():0 > > It got me thinking about an option where the compiler will rewrite usage > of strict equality where there is almost no performance difference in > order to reduce code size and number of variables that need initialization. > > Again, we don't have to all agree. We can teach the compiler to do > different things at different points. > > Thoughts? > -Alex > > >
