On 7/26/16, 12:49 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>On Jul 26, 2016, at 10:39 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>> On 7/26/16, 11:39 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>>>
>>> On Jul 26, 2016, at 8:15 PM, Alex Harui <aha...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>> On 7/26/16, 1:40 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>
>>>>> I noticed a couple of things:
>>>>> 1. There’s lots of String(val) casts in FlexJS code. This practice is
>>>>> considered “bad” practice in Javascript where implicit conversion is
>>>>> generally quicker. So in a case where a number can be converted
>>>>> implicitly, the cast should be completely skipped and even when a
>>>>> number
>>>>> needs to be converted to a string, “” + val is more efficient than
>>>>> String(val). This is especially true in FlexJS where (I believe) such
>>>>> code will result in org.apache.flex.Language.as(val,”String”).
>>>>
>>>> I'm not seeing this. What source code is generating String(val)
>>>>calls?
>>>> Regarding optimization, do we know if GCC will do this ("" + val)
>>>> optimization for us?
>>>>
>>>> In general, there is a big TODO around type conversions.
>>>
>>> Good question. I just checked and there’s both String() and toString()
>>> calls in the optimized code. One example:
>>> return RA+String(a)+bc+String(this.alpha)}; It’s coming from one of the
>>> Graphic classes.
>>
>> It would save me time to not have to search through the code for test
>> cases if you have them handy.
>
>I already replaced this one. Are you saying you are thinking of doing
>this replacement in the compiler? I’m not sure it’s really necessary.
>Implicit string conversions should be fine in Flash as well.
I guess I misunderstood. I thought you were saying the generated code had
un-wanted String() calls. If it is in the source itself, then that's fine
if you are sure the implicit conversion will "do the right thing". I've
been burned enough that I probably am the person that adds these
unnecessary calls.
-Alex
