Yeah, ++foo should be faster++ though the results were exactly the
same when I tested for like 2K iterations. Still, can be changed.
It remain from the former version, where start++ !== end was used (
!== instead of < ). It was then safe to use that operator only with
the pluses on right.
!== should be faster than <, but again, the results were the same, so
I just chose the shorter one.
On Tue, Nov 4, 2008 at 6:42 PM, Andrea Giammarchi
<[EMAIL PROTECTED]> wrote:
> P.S. there is a logic problem, and probably a performances improvement using
> ++start instead of start++
>
> function myBestTrim( str ){
>
> var start = -1,
>
> end = str.length;
>
> while(str.charCodeAt(--end) < 33);
>
> while(++start < end && str.charCodeAt(start) < 33);
>
> return str.slice( start, end + 1 );
>
> };
>
> In your code start++ is obviously less than end since value === 0 for the
> first case will be true only on right side, the charCodeAt
>
> I know it was just a silly error and just one more boolean evaluation that
> does not make that difference, but why do not fix it ;-)
>
> On Tue, Nov 4, 2008 at 9:34 PM, Andrea Giammarchi
> <[EMAIL PROTECTED]> wrote:
>>
>> Ariel,
>> I read now the myBestTrim function.
>>
>> You check charCodeAt less than 33, but in the precedent version you used
>> these chars:
>> chars = '
>> \n\r\t\v\f\u00a0\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u200b\u2028\u2029\u3000';
>>
>> I wonder which side effect could we have ignoring thos u2XXX characters,
>> that as far as I know, are not included in range 0, 33 ... am I wrong?
>>
>> On Tue, Nov 4, 2008 at 9:28 PM, Andrea Giammarchi
>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> On Tue, Nov 4, 2008 at 5:58 PM, Ariel Flesler <[EMAIL PROTECTED]> wrote:
>>>>
>>>> P.S: I knew you'd be throwin' in your super revolutionary version of
>>>> it.. so predictable :-P
>>>
>>> :D
>>>
>>> mine was just a suggestion. Clever or recent browsers cast as constant
>>> the regexp, but to be sure it happens everywhere, you can "force" in that
>>> way.
>>>
>>> My point is that I still cannot believe a runtime code works faster than
>>> a regexp that should perform exactly the same in core. This could depend on
>>> regexp engine, but we are still talking about compiled C against runtime
>>> interpretated code (unless we are not under V8, TraceMonkey, or SquirrelFish
>>> Extreme)
>>>
>>> In any case, I tested the same over this string: Array(1000).join(" test
>>> ") and you are right, your performs in a reasonable time, while the RegExp,
>>> casted or not, asks me to stop the script execution.
>>> This is hilarius to me, and I can think about a regexp engine problem
>>> more than a bad practice, so I guess your porposal makes sense enough, since
>>> it is a must for big strings, a little bit slower for small strings.
>>>
>>> Cheers
>>
>
>
> >
>
--
Ariel Flesler
http://flesler.blogspot.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
