Hot on the heels of yesterday’s discussion of Jiffy come a few unrelated notes involving client side performance testing. It looks like this approach is finally gathering the mindshare it deserves, and it’s really cool to see all the effort going into developing these solutions.
The first is a fairly basic client side performance tracker for Rails by Eric Falcao. Currently, it appears to only track the time from the start of the document parse to the onload event. Eric could make this a really compelling tool by providing an API allowing the developer to add more granular timings as desired. This is the approach I’ve used in the prototype Rails client side perf tool I used for Dojo Charts measurements (and a couple of other projects), and it’s also the approach used by Jiffy.
You could then hook into prototype.js or RJS code generators to auto-insert these performance counters for common actions (here’s an example — time every XHR fired on behalf of every end user). To use Eric’s words, there are some really cool ways to make this type of instrumentation “we’re-all-spoiled-with-rails simple.”
Next is a really cool cross-browser benchmark of SVG, VML, and Canvas by Ernest Delgado. Ernest uses two case studies of Google Maps charting to compare SVG (for Safari and Firefox) and VML (for IE) with a Canvas implementation. I’ve done some studies of the relative performance of VML and SVG, but I’ve never looked at how a Canvas implementation could compare.
Ernest’s findings are interesting. In my research, Firefox’ SVG implementation was notably slower than Safari’s, and Ernest’s data bears that out for Firefox 1 and 2. But Firefox 3 renders SVG in his case studies in between 1/2 and 1/3 time time of Firefox 2, so it appears the team has done some solid work on the SVG engine (or, perhaps, performance improvements elsewhere in the browser are responsible for the gains).
Compared to Safari 3, Firefox 3 turns in a mixed performance. In the first case, Firefox is significantly faster. In the second case, Safari is faster. I would like to know more about the sample size of the measurements to see if these numbers would hold up, but it definitely looks like the Mozilla team has been hard at work.
Speaking of the Mozilla team, John Resig last week described a new plugin for deep profiling jQuery. This plugin will instrument every jQuery call and give some basic stats as to call count and time spent. And this is just the beginning. Per John:
The next stage of development for this plugin would be to reveal which methods are running inside other jQuery methods – in addition to monitoring other aspects of the application (such as timers, Ajax callbacks, etc.). I’m pleased with even this most-basic result – it gives me the ability to quickly, and easily, learn much more about a jQuery-using application.
Clearly, the complexity of apps being run on the client side requires more measurement within the browser. That’s why we’re seeing a mini-explosion of browser side performance collection tools or demos. This is a space ripe for innovation.