Hello Chris, On Tue, Aug 26, 2008 at 13:38, Chris Lee-Messer <[EMAIL PROTECTED]> wrote: > Adding Sizzle sounds like a substantial plus, I noticed that your > addition fixes the errors in MochiKit.Selector. Does it break any of > the other (non-selector related) tests in MochiKit?
No, no tests outside the Selector module are broken. You can run the test suite here: http://www.hvergi.net/arnar/public/mochikit/tests/ There is some namespace pollution, i.e. the Sizzle code defines a few globals. Maybe we should hide them inside some MochiKit.Selector.__internal__ object or similar? The Selector module has limited usability now imo, so I think this would be a good move even though it breaks backwards compatibility a bit. > p.s. I'm running firefox 3.1pre now with the JIT running, and > slickspeed tests are interesting as your version of MochiKit.Selector > is reported as faster than Sizzle: most of the response times are 1ms > for a total time of 45ms vs 174ms for Sizzle itself. I would guess > that some compiled code is being cached. MochiKit's current Selector > comes in with a time of 4045ms. Yes, I noticed the same when I ran the benchmark, but not so drastically. I added a second instance Sizzle to the test suite, at the very end. That one gives lower times so indeed there seems to be some caching of compiled code going on. http://www.hvergi.net/arnar/public/sizzle/speed/# cheers, Arnar --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" 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/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
