Work on GQuery progresses, Comment on Slickspeed

GQuery is progressing nicely. I implemented all of CSS3 selectors by following ExtJS's DomQuery implementation, only I added the ability to parse at runtime as well as via a generator at compile time. The compile time generator turns a CSS selector into 100% inlined code. That is, a selector like "#foo", will turn into "return document.getElementById("foo");", no parsing step involved. I've still got a bunch of optimizations to make, add support for XPath and native getElementsByClassName, but even now working with the library in GWT is very cool. I just started looking at DomAssistant as well, to incorporate (i.e. steal) the best algorithms from each.

I've been using SlickSpeed to evaluate compliance of my implementation, as well as check performance, but I noticed an issue with SlickSpeed's benchmarking which is endemic to a lot of microbenchmarks: failure to account for timer resolution.

When you run SlickSpeed on some browsers/operating systems, alot of the results will be 0ms, 4ms, 8ms, or some other multiple, because the Javascript Date.getTime() function has a fixed update resolution on some system, for example, on some systems it seems to be around 16ms or roughly 1 screen update (60Hz = 1/60th second). SlickSpeed runs each selector 4 times, and then divides by 4, which is why you see results like 4ms, 8ms, and the like.

The problem is, there is always the issue of timer jitter and aliasing. For example, if you happen to sample the timer twice before the next update happens, you end up with a 0ms result, even if it took 15ms, whereas if you get unlucky and start the benchmark half way into an update interval, you may record a result rounded up to the next. I need to hack SlickSpeed anyway to allow it to bench GWT, and in the process I'm going to run each selector such that the time exceeds 500ms, plus toss out the min/max values to evaluate the effectiveness of caching on some of those APIs. This will disadvantage my compile time selectors, which avoid a parsing step, but be more fair to comparing the actual implementation of the selector routines. I might make a separate benchmark to time 'setup' speed that these libraries use for parsing the selector, since that is obviously a factor in many end user apps that don't neccessarily run the same query more than once.

-Ray