Prototype

Comments and changes to this ticket

• 

  Juriy Zaytsev May 29th, 2008 @ 12:10 AM

  • → State changed from “new” to “enhancement”
• 

  John-David Dalton May 29th, 2008 @ 04:46 AM

  • → Assigned user changed from “” to “Juriy Zaytsev”
  • → Milestone changed from “” to “1.6.1”
• 

  Steven Levithan May 29th, 2008 @ 11:54 AM

  As I've (indirectly) noted on by blog at http://blog.stevenlevithan.com/a... , this implementation is a bad idea.

• 

  jodosha May 29th, 2008 @ 12:24 PM

  I tested with the original Steven benchmark suite, the algorithm is faster than others when deal with whitespaces up to 100 (on both string sides). With 1k of whitespaces is slower than others.

  This meant it's not so much scalable, because increase the execution on the whitespaces increasing.

  Now the question is: Is it better to have a general purpose algorithm (scalable) or an implementation which it's faster on short strings (un-scalable)? Do our webapps should handle 2k (1+1) of whitespaces on the client-side?

• 

  Steven Levithan May 29th, 2008 @ 10:20 PM

  @jodosha, IMHO any non-freaky implementation of trim is fast enough in most cases. It is specifically the edge-cases -- the long strings, the unexpected strings -- where performance matters most.

  A trim method that performs more or less consistently relative to the lengths of the strings it works with is, again IMO, much better than an implementation that has the potential to cause a nasty performance dip and temporarily freeze the page when working with pathological cases.