Justin seems to have observed the Google compiler stripping these out. It seems
like a good idea to do some research on how extensively it does so. If we can
rely on goog to do this work for us, then I’m fine with that.
Either way, the performance implications one way or the other are miniscule. I
see this as a “nice to look into” feature for one day when there’s cycles for
it, but for now I have plenty of bigger fish to fry. ;-)
We should probably capture this in a JIRA though.
> On Jun 12, 2017, at 7:19 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Yep. We are introducing "just-in-case" code. These changes are not PAYG,
> until we get more of these optimizations in. I'm still interested in how
> many of these cases there are. Some day I'll find out. But probably not
> right away.
>
> -Alex
>
> On 6/11/17, 1:21 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> It seems like the general case is better to have the initialization.
>> Thanks for implementing that.
>>
>> It would probably be nice for the compiler to be intelligent and only
>> initialize if the code does not initialize too.
>>
>> So:
>>
>> var val:Boolean;
>> // further down before val is actually accessed
>> val = true;// or val = false;
>>
>> should not initialize val, but:
>>
>> var val:Boolean;
>> // further down
>> if(val == someotherval){
>> // do something
>> }
>> should initialize it.
>>
>> But I don’t see this as critical for now.
>>
>> Harbs
>>
>>> On Jun 11, 2017, at 10:56 AM, Justin Mclean <jus...@classsoftware.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>>> The changes you made look fine.
>>>
>>> Do you want them as the default and an option to turn them off? I’m
>>> assuming you will you at some later point add other switches to turn
>>> other optimisations (whatever they may be) on?
>>>
>>>> Seems like eventually we'll have to initialize other types as well.
>>>
>>> I’d guestimate there would be a performance boost for string and for
>>> object as well / but the size cost may be different. Won't know until I
>>> or someone tries it.
>>>
>>>> Safe, but inefficient at times.
>>>
>>> So far I not seen any inefficiency in fact the opposite. But sure there
>>> may be specific cases that perform better, please post any you find to
>>> the list.
>>>
>>> Thanks,
>>> Justin
>>
>
