Last suggestion. The charCodeAt(--end) returns NaN when end is negative, and NaN < 33 is false. We can use this trick on start variable as well, removing one check for each character.
As summary, I wonder which performances could have this version: function myBestTrim( str ){ var start = -1, end; if(end = str.length){ while(str.charCodeAt( --end ) < 33); while(str.charCodeAt( ++start ) < 33); str = str.slice( start, end + 1 ); }; return str; }; Which seems to work fine for me. Regards. On Tue, Nov 4, 2008 at 9:44 PM, Andrea Giammarchi < [EMAIL PROTECTED]> wrote: > P.S.2 ... in php for example ++$var is a bit faster than $var++ , dunno in > JS which one performs better, that was the other improvement that is true in > my old laptop > > > On Tue, Nov 4, 2008 at 9: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 >>>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---