Here is a link [1] to you saying "I’m a strong believer in getting it to work first, then optimise it, premature optimisation wastes time and often makes incorrect assumptions."
This is an interesting topic, but I want to make sure this isn't premature optimizing. And me, I just want to get it to work and get a release out. IMO, the key to success for Flex is developer productivity. Because we have a couple of compilers in the workflow (FalconJX and Google Closure Compiler), we have a couple of chances to make good small code that runs well. Manually trying to determine whether to use "==" or "===" might be better left to tooling someday, so folks don't have to worry about it and can just get their features to work first. I don't want to tell folks, "sorry, we don't have AMF support yet, but we've made sure we've used strict equality!". IMO, if folks can be more productive by using common patterns and we can generate better code, then everybody wins. I'd personally lean towards warning when folks use JS patterns that can cause trouble. JS lets you do lots of things and the value undefined can get you in a lot of trouble, but AS lets you do fewer things that can get you in trouble. Undefined is only allowed for type '*' for example. So if we can know that a string can't be null, then maybe the compiler should always generate "===" even if you wrote "==". For uninitialized references to instances, maybe leaving it uninitialized and using "== null" is best. Or maybe there isn't a right answer and folks will want compiler options to generate better code. AS gives us real type information. What is the point of initializing properties if there is a guarantee that they'll be initialized in other code before it is ever tested. Code like: var foo:String; if (someCondition) foo = "bar"; else foo = "foo"; Ints are initialized to zero because the common patterns fail if you don't, not just because of "==" tests. There are articles about JavaScript type inferencing in V8 and WebAssembly is sort of implying something similar if I understand it correctly so type "annotation" may eliminate some of the need to choose between "==" and "===". Sounds like the CSS code, which does use '*' could be improved by not using "==" so much. And that in many cases string compares can be faster with "===". That's great. But there might be other ways to end up with better code than manually scrubbing the source. Of course, I could be wrong... -Alex [1] http://mail-archives.apache.org/mod_mbox/flex-dev/201703.mbox/%3cDB1BB6CD-B 373-4d82-8b72-6491a306f...@classsoftware.com%3e On 6/3/17, 6:40 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: >Hi, > >So here’s some data for you: > >In string_old.js: > >var s; > >for (var i = 0; i < 1e8; i++) { > if (s == "") { > } >} > >In string.js: > >var s = ""; > >for (var i = 0; i < 1e8; i++) { > if (s === "") { > } >} > >time node string.js >real 0m0.246s >user 0m0.114s >sys 0m0.046s > >time node string_old.js >real 0m2.496s >user 0m2.452s >sys 0m0.019s > >The === and setting to “" is an order of magnitude faster (in node >anyway), similar results with initialising to null rather than “”. > >Running similar code (converted to AS ) through the chrome profiler gives >results where setting to null and using === is faster. > >It even twice as fast if you initialise the variable and compare on every >time through the loop. So 1e8 lots = null and a === is faster than no >initialisation and a ==. > >I think what is happening currently is that because we are not >initialising the variable it’s doing a implicit cast on every every >comparison that is very expensive when using != and ==, using === and !== >significantly speeds this up but then you have the issues of uninitialise >strings and objects being null in AS and undefined in JS but it still >twice as fast. > >BTW I do note that we are setting ints to 0. I assume because of similar >reasons? But it seems you were not concerned with the overhead of this? > >Thanks, >Justin
