Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
MIME-Version: 1.0
In-Reply-To: <D3BCE601.71796%aharui@adobe.com>
References: <DD6C0257-ECA9-454A-B297-41786EE47F0C@gmail.com> <D3BCE601.71796%aharui@adobe.com>
From: Josh Tynjala <joshtynjala@gmail.com>
Date: Tue, 26 Jul 2016 10:28:33 -0700
Message-ID: <CADZSWG467niDj48cmyjT5=+8K7fcRMSef1jnQ2q4UBPS8nK5Mw@mail.gmail.com>
Subject: Re: [FlexJS] Javascript efficient code patterns
To: dev@flex.apache.org
Content-Type: multipart/alternative; boundary=94eb2c070d2041328905388d3d3e
archived-at: Tue, 26 Jul 2016 17:29:19 -0000

--94eb2c070d2041328905388d3d3e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yeah, push() is terribly bad for performance because of the GC overhead
from the ...rest Array. In Starling and Feathers, we always try to avoid
push() whenever possible. We usually use bracket syntax instead:

array[array.length] =3D newValue;

In loops, it's possible to use a local integer counter instead of checking
the length property every time.

counter =3D 0; //or counter =3D array.length, if it isn't empty
for(...)
{
    array[counter] =3D newValue;
    counter++;
}

- Josh


On Tue, Jul 26, 2016 at 10:15 AM, Alex Harui <aharui@adobe.com> wrote:

>
>
> On 7/26/16, 1:40 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>
> >I noticed a couple of things:
> >1. There=E2=80=99s lots of String(val) casts in FlexJS code. This practi=
ce is
> >considered =E2=80=9Cbad=E2=80=9D practice in Javascript where implicit c=
onversion 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, =E2=80=9C=E2=80=9D + val is more effi=
cient than
> >String(val). This is especially true in FlexJS where (I believe) such
> >code will result in org.apache.flex.Language.as(val,=E2=80=9DString=E2=
=80=9D).
>
> 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.
>
> >
> >2. String concatenation: I=E2=80=99m not sure how much of an issue this =
is in
> >current browsers, but using aray.join() to build a string was MUCH faste=
r
> >than building strings using the plus operator. For longer strings the
> >difference was dramatic.
>
> If I understood this, it would be hard for the compiler to generate the
> right code for all browsers.  You could create a StringBuilder class that
> checks platforms and runs different code at runtime.
>
> FWIW, Flex UIDUtils uses ByteArray because, IIRC, while array.join() migh=
t
> be fast, the array.push() is horribly slow and generates a lot of GC
> activity.
>
> HTH,
> -Alex
>
>

--94eb2c070d2041328905388d3d3e--