On 2/16/17, 11:59 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> On Feb 17, 2017, at 12:43 AM, Alex Harui <aha...@adobe.com> wrote:
>>
>>
>>
>> On 2/16/17, 2:34 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>>>> Well, that's not PAYG (yes, I'm being picky).
>>>
>>> I disagree. For string it certainly is PAYG. There’s no extra cost.
>>>(and
>>> considering the three bytes of ‘=“”’ in the source code is getting
>>>petty
>>> IMO)
>>
>> Pretty sure that uninitialized variables do not have any presence in
>> minified JS. So every variable where you do this is adding
>>
>> foo.bar = "";
>>
>> to the app.
>
>That does not sound right. It seems to be a change in behavior.
>
>Either way, it should be foo.prototype.bar=“”.
AIUI, the minified code would be a.bar. They assign a temp var to
MyClass.prototype.
>
>Additionally, I mentioned a while back, that the code which falcon
>produces is not optimized for minimization. Instead of
>foo.prototype.bar;foo.prototype.baz; etc. it should output foo.prototype
>= {bar:””,foo:10} unless it is subclassing something else and the
>prototype needs to be added to. in that case, the code should produce
>something like this:
>(function(){var p = foo.prototype;p.bar=“”;p.baz=10;}())
>
>This is not something super important. There’s probably functionality
>which should happen first, but these changes would make a much bigger
>difference in app size (and probably loading as well) than some
>initialized values.
My understanding is that Google Closure Compiler, which does the
optimization, relies on us using foo.prototype.bar with JSDoc. For some
reason they have not chosen to output structures. If you are certain it
is more efficient, you should see if has been suggested on their issues
list. I am hopeful we do not have to get into the JS optimization game.
I hope we can rely on Google.
>
>>> Adding an extra TextModelWithEmptyStringDefaults is totally
>>>unnecessary.
>>>
>>>> Again, what
>>>> percentage of the time in production will a label's text property not
>>>>be
>>>> set to something other than “"?
>>>
>>> More than you’d think. We ran into this because we were using
>>> ImageAndTextButton without text. But it’s quite common to have
>>>components
>>> which get text or not at runtime.
>>
>> Then use ImageButton. Or swap in a different model with empty string
>> defaults for ImageAndTextButton.
>
>ImageButton is horribly broken at the moment. It uses input rather than
>button as the other “Button”s do. It’s not very style-able, and the image
>is shown double to boot. It need to be changed to a button element and
>fixed up.
>
>> For just one occurrence, you probably won't notice, But after we
>> initialize 100 or 1000 properties to "" you might notice.
>
>No. I don’t buy this. You’d need tens of millions of initializations to
>have a measurable effect. If there are that many class initializations,
>it will still not be noticeable because there will be so many bigger
>performance bottlenecks, that it would still not be noticeable. Again,
>this is just class initialization, so there’s no cost for object
>instantiations. The solution of adding additional model classes is worse
>than the problem.
In another thread, you pointed out that MaterialIconType added 77K to the
code. Don't all of these assignments add up to the same thing?
>
>Additionally, initializing variables might actually *help* performance in
>javascript because it allows the runtime to infer the type.[1]
>
>[1]https://wildlyinaccurate.com/javascript-performance-variable-initializa
>tion/
><https://wildlyinaccurate.com/javascript-performance-variable-initializati
>on/>
In this article it tests assigning a default value of null vs a default
value of a type. I am proposing not assigning any default value at all.
Then on the first actual assignment, the runtime will infer the correct
type.
Thanks,
-Alex
