You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Maurice Amsellem <ma...@systar.com> on 2013/11/14 00:35:05 UTC
Question on StringUtil.trim
Hi,
I have noticed that trim will return a copy of the string argument even if there are no spaces, instead of returning the original string.
public static function trim(str:String):String
{
...
if (endIndex >= startIndex)
return str.slice(startIndex, endIndex + 1);
else
return "";
Is that intended behavior (maybe for compatibility, or something ...) ?
Maurice
RE: Question on StringUtil.trim
Posted by Maurice Amsellem <ma...@systar.com>.
Thanks Benoit. So it's slice that does the optimization.
Maurice
-----Message d'origine-----
De : Benoit Wiart [mailto:b.wiart@ubik-ingenierie.com]
Envoyé : jeudi 14 novembre 2013 09:03
À : dev@flex.apache.org
Objet : 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 any memory allocation
Le 14 nov. 2013 à 05:33, Alex Harui <ah...@adobe.com> a écrit :
>
>
> On 11/13/13 8:23 PM, "labriola@digitalprimates.net"
> <la...@digitalprimates.net> wrote:
>
>>> No idea. I was trying to think of any danger of manipulating the
>>> returned string if it is the original and not always a copy, but I
>>> can't think of anything off-hand.
>>
>>> Is it much faster to add the check and return the original?
>>
>>
>> Aren't AS strings immutable anyway? So, the method got a copy to
>> begin with from the stack, but it is always a copy so, if the check
>> is any faster, returning the original shouldn't be able to cause an issue.
> I don't really know how it works. I think Strings are effectively
> 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
> thought you just got the pointer/reference, but someone could verify
> that with a profiler. I also don't know if there is a quick check
> inside String.slice that returns the original if the indexes indicate
> the entire string.
>
> -Alex
>
Re: Question on StringUtil.trim
Posted by Benoit Wiart <b....@ubik-ingenierie.com>.
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 any memory allocation
Le 14 nov. 2013 à 05:33, Alex Harui <ah...@adobe.com> a écrit :
>
>
> On 11/13/13 8:23 PM, "labriola@digitalprimates.net"
> <la...@digitalprimates.net> wrote:
>
>>> No idea. I was trying to think of any danger of manipulating the
>>> returned string if it is the original and not always a copy, but I can't
>>> think of anything off-hand.
>>
>>> Is it much faster to add the check and return the original?
>>
>>
>> Aren't AS strings immutable anyway? So, the method got a copy to begin
>> with from the stack, but it is always a copy so, if the check is any
>> faster, returning the original shouldn't be able to cause an issue.
> I don't really know how it works. I think Strings are effectively
> 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
> thought you just got the pointer/reference, but someone could verify that
> with a profiler. I also don't know if there is a quick check inside
> String.slice that returns the original if the indexes indicate the entire
> string.
>
> -Alex
>
Re: Question on StringUtil.trim
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/13 8:23 PM, "labriola@digitalprimates.net"
<la...@digitalprimates.net> wrote:
>>No idea. I was trying to think of any danger of manipulating the
>>returned string if it is the original and not always a copy, but I can't
>>think of anything off-hand.
>
>>Is it much faster to add the check and return the original?
>
>
>Aren't AS strings immutable anyway? So, the method got a copy to begin
>with from the stack, but it is always a copy so, if the check is any
>faster, returning the original shouldn't be able to cause an issue.
I don't really know how it works. I think Strings are effectively
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
thought you just got the pointer/reference, but someone could verify that
with a profiler. I also don't know if there is a quick check inside
String.slice that returns the original if the indexes indicate the entire
string.
-Alex
RE: Question on StringUtil.trim
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>No idea. I was trying to think of any danger of manipulating the returned string if it is the original and not always a copy, but I can't think of anything off-hand.
>Is it much faster to add the check and return the original?
Aren't AS strings immutable anyway? So, the method got a copy to begin with from the stack, but it is always a copy so, if the check is any faster, returning the original shouldn't be able to cause an issue.
Re: Question on StringUtil.trim
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi,
>
>I have noticed that trim will return a copy of the string argument even
>if there are no spaces, instead of returning the original string.
>Is that intended behavior (maybe for compatibility, or something ...) ?
No idea. I was trying to think of any danger of manipulating the returned
string if it is the original and not always a copy, but I can't think of
anything off-hand.
Is it much faster to add the check and return the original?
-Alex