[FlexJS] more on undefined / non initialised values

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Justin Mclean
Administrator
Hi,

If you were wondering about the size here’s the results.

The release version was 1441523 bytes before the change and 1441458 bytes after the change i.e. it become smaller by about 1/10000 of a % after the Numbers an Booleans were initialised. I guess google optimisation works in mysterious ways :-)

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Alex Harui-2
In reply to this post by Justin Mclean
I never said it wasn't important/serious.  I did not say it is an
optimization issue.

The changes you made look fine.  Seems like eventually we'll have to
initialize other types as well.  It makes every variable be like every
airline passenger going through the metal detector.  Safe, but inefficient
at times.  There are other options out there that are less safe and more
efficient in certain scenarios.  That's how optimization often works.  It
detects certain patterns and optimizes for them.  Me, I'd happily change
the way I write code in order to leverage these optimizations.  Some folks
will agree, some won't, doesn't matter, there'll be options to control the
output.

-Alex

On 6/10/17, 8:12 PM, "Justin Mclean" <[hidden email]> wrote:

>Hi,
>
>So to summarise this thread.
>- discussing if Boolean be initialised to false and Numbers to NaN
>- Code can act differently on AS and JS when these initialisers are not
>present
>- Josh and I think this a serious bug
>- Harbs also sees the issue
>- Piotrz also wants Booleans and Numbers to be initialised
>-  Alex thinks this is an optimisation issue
>
>I’ve went ahead and made the change and checked into a new initialization
>branch of falcon.
>
>Testing with a real world application gave no notable size increase and
>improved performance by 10% on JS. Mostly I would guess due to use of ==
>and != in the framework and implicit casting that goes on when when
>comparing uninitialised variables.
>
>Thanks,
>Justin

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Justin Mclean
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Harbs
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Harbs
In reply to this post by Justin Mclean
var start = Date.now();
var val;
for(var i=0;i<1000000;i++){
        val=false;
        val=false;
}
console.log(Date.now()-start);

V8 (Node.js and Chrome) seems to optimize this loop out, so you can do a billion iterations really fast. Firefox gives a more realistic indication of performance:

This takes about 700 ms for a million iterations on my machine. Setting it once instead of twice cuts off about 100ms.

Harbs

> On Jun 11, 2017, at 10:56 AM, Justin Mclean <[hidden email]> wrote:
>
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Justin Mclean
Administrator
In reply to this post by Harbs
Hi,

> But I don’t see this as critical for now.

This is probably not required as the google compiler take care of this for us.

Code like this:
function test() {
 var a = false;
 a = b;
 if (a) {
  Console.log("got here");
 }
}

Becomes:
function test(){b&&Console.log("got here”)}

In this case both assignments are removed.

It even smart enough to turn this:
function test() {
 var a = false;
 var b = false;
 a = true;
 if (a && b) {
  Console.log("got here");
 }
}

Into nothing.
function test(){}

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Alex Harui-2
In reply to this post by Harbs
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" <[hidden email]> 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 <[hidden email]>
>>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
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Harbs
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Peter Ent-2
In reply to this post by Harbs
Perhaps we can look to other languages for guidance. For example, in Swift:

var val:Boolean

is illegal. It MUST be initialized or declared to be optional:

var val:Boolean = false
var val:Boolean?

The Swift people felt that leaving variables uninitialized and defaulted
caused too many issues and so force values to be given. If you don't have
a value then you must declare it to be optional, in which case its value
is nil until it is assigned a value.

Neither AS nor JS has the luxury of syntax that enforces this, but perhaps
we could have the compiler issue a warning (at least) that scalar values
are uninitialized.

‹peter

On 6/11/17, 4:21 AM, "Harbs" <[hidden email]> 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 <[hidden email]>
>>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
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Alex Harui-2
Sounds like the Google Closure compiler can optimize out unnecessary
initialization, so I think the plan of finishing up adding initialization
is the right change for the our compiler.

At least, that how I understand the situation,
-Alex

On 6/12/17, 8:16 AM, "Peter Ent" <[hidden email]> wrote:

>Perhaps we can look to other languages for guidance. For example, in
>Swift:
>
>var val:Boolean
>
>is illegal. It MUST be initialized or declared to be optional:
>
>var val:Boolean = false
>var val:Boolean?
>
>The Swift people felt that leaving variables uninitialized and defaulted
>caused too many issues and so force values to be given. If you don't have
>a value then you must declare it to be optional, in which case its value
>is nil until it is assigned a value.
>
>Neither AS nor JS has the luxury of syntax that enforces this, but perhaps
>we could have the compiler issue a warning (at least) that scalar values
>are uninitialized.
>
>‹peter
>
>On 6/11/17, 4:21 AM, "Harbs" <[hidden email]> 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 <[hidden email]>
>>>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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] more on undefined / non initialised values

Justin Mclean
Administrator
Hi,

So I’ve just checked in a compiler option to turn the initialisers for Number and Boolean off just is case you want to optimise this in other way.

If there are no objections or further suggested changes I’ll merge into develop next week sometime.

YMMV but once merged if you do turn them off it's likely you have less performance and more bugs. I have a couple of these [1] and I’ll send you one :-)

Thanks,
Justin

1. http://shop.evilmadscientist.com/productsmenu/62
12