> 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=“”.
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.
>> 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.
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-initialization/
<https://wildlyinaccurate.com/javascript-performance-variable-initialization/>
Harbs
> My 2 cents,
> -Alex
>
