I suppose a few % points off isn't that much of a difference and in some cases were even better. But I expect mine isn't too far off the test machine.
Think I got my maths the wrong way round: ((1.2.3 time - 1.2.6 time) / 1.2.3 time) * 100 e.g. for .extend(): ((63 - 46) / 63) * 100 (17 / 63) * 100 = 27% improvement Maybe that's why I made that conclusion. What I am interested in is how the lower spec PC's performed (non-dual core, entry level machines), to see if multi-core processors actually make much of a difference (since many users of website using jQuery will have these type of PC's). .map() is the major improvement in this release as a few milliseconds off a fast method like .extend() won't mean as much (although if it is called a lot it adds up to more savings). .offset() is still a bottleneck (browser quirks stop any major improvements), but caching values and restricting how often it is called helps mitigate that (I think Flash is still far smoother when it comes to mouse tracking and animation - which can be very slow over a Citrix connection). Animation performance is not something that can be tested with unit tests (still need a human to do that). How does it compare with other libraries now? -Sam On Jun 4, 1:21 pm, "John Resig" <[EMAIL PROTECTED]> wrote: > > Still a performance improvement, but not as great as the test machine > > - i.e. the faster the client PC processor, the better the performance > > improvement (I don't think RAM will have much of an impact as the CPU > > is doing the work). > > How so? Your .extend() improved by 37% and your .map() improved by > 1017%. Those are well within the realm of what we posted. The speed of > the processor shouldn't affect the degree of relative improvement. > > --John
