Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (nike.apache.org: domain of maurice.amsellem@systar.com
 designates 66.129.85.153 as permitted sender)
From: Maurice Amsellem <maurice.amsellem@systar.com>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Subject: RE: Question on StringUtil.trim
Thread-Topic: Question on StringUtil.trim
Thread-Index: AQHO4Q/zAJOnAHIUSGa6vvQ22X8yZZokXolQ
Date: Thu, 14 Nov 2013 08:07:50 +0000
Message-ID: 
 <2095F5EBE04D59409DFCE91FFCEBF7AF3F5483CF@EXMBX05.netplexity.local>
References: <CEA991E3.118F8%aharui@adobe.com>
 <3906BA9F-BC6C-4F91-9CED-7D6C8E885901@ubik-ingenierie.com>
In-Reply-To: <3906BA9F-BC6C-4F91-9CED-7D6C8E885901@ubik-ingenierie.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks Benoit.  So it's slice that does the optimization.

Maurice

-----Message d'origine-----
De=A0: Benoit Wiart [mailto:b.wiart@ubik-ingenierie.com]=20
Envoy=E9=A0: jeudi 14 novembre 2013 09:03
=C0=A0: dev@flex.apache.org
Objet=A0: Re: Question on StringUtil.trim

I had the same question a few weeks ago
And I think the fash sdk is optimized in this case as Scout didn't report a=
ny memory allocation


Le 14 nov. 2013 =E0 05:33, Alex Harui <aharui@adobe.com> a =E9crit :

>=20
>=20
> On 11/13/13 8:23 PM, "labriola@digitalprimates.net"
> <labriola@digitalprimates.net> wrote:
>=20
>>> No idea.  I was trying to think of any danger of manipulating the=20
>>> returned string if it is the original and not always a copy, but I=20
>>> can't think of anything off-hand.
>>=20
>>> Is it much faster to add the check and return the original?
>>=20
>>=20
>> Aren't AS strings immutable anyway? So, the method got a copy to=20
>> begin with from the stack, but it is always a copy so, if the check=20
>> is any faster, returning the original shouldn't be able to cause an issu=
e.
> I don't really know how it works.  I think Strings are effectively=20
> immutable because there is no "in-place" manipulation APIs (no setCharAt)=
.
> I don't think you get a copy on the stack, but I could be wrong, I=20
> thought you just got the pointer/reference, but someone could verify=20
> that with a profiler.  I also don't know if there is a quick check=20
> inside String.slice that returns the original if the indexes indicate=20
> the entire string.
>=20
> -Alex
>=20