Hi, > I wasn't claiming that for was any less great than each! I was > complaining about looping a concat vs. doing a join at t the end...
Erm, did I discuss that somewhere? You answered to my posting. The concat vs. join stuff was Sam. My point was to take the check for XMLSerializer out of the function by emulating it when it is not yet implemented. That is not only a little bit faster. It is a more general solution which is much more important than the rather marginal speedup. > and other micro effeciencies. I gave up tiny-tuning code when I gave > up assembler. There are situations where you need speed optimizations. Especially with languages like JavaScript, where some interpreters are really slow, it happens as soon as you work with big datasets. I like to spot eventual performance improvements to keep me trained for the cases I need to. > I tell this to all my programmers, You can't compare a little > application code time to the time it takes to do a big IO (or http or > sql...). It all depends on how often you run the loop and how much overhead the "optimization" needs. If the loop costs maybe 10 bytes of JS-code and is run some 10000 times the optimization will probably pay. Of course a "optimization" in one function that slows down other stuff so much that the complete system gets slower is no real optimization. > I tend to be opinionated about certain things... I am an XSL guy, I > don't like incrementing! (a for loop works when there is little else!) As I said: "With such a simple function in each() you might also consider to use a normal for-loop." Note "simple function" and "might consider". I think we actually do agree here: for() is OK in such simple cases if performance matters. In more complicated cases each() makes the code better readable. I also think that Sams optimization is OK, if performance matters (i.e. the function is called very often with huge datasets). Christof _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
