Comments on: If you are reading this post, you are contributing to a benchmark http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/ A blog by Ryan Breen of Gomez Mon, 01 Dec 2008 22:42:41 +0000 http://wordpress.org/?v=2.6.2 By: Ajax Performance » Client side performance testing has arrived http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-69568 Ajax Performance » Client side performance testing has arrived Wed, 25 Jun 2008 04:55:04 +0000 http://www.ajaxperformance.com/?p=28#comment-69568 [...] 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 [...] [...] 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 [...]

]]> By: Ajax Performance » Click a link, help a worthy cause http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-4392 Ajax Performance » Click a link, help a worthy cause Wed, 04 Apr 2007 21:26:54 +0000 http://www.ajaxperformance.com/?p=28#comment-4392 [...] Frequent readers will recall that, a few months ago, I built a performance instrumentation package which supported the collection and aggregation of performance metrics from inside an end user’s browser. Timings are communicated up to a Rails app at aelite.ajaxperformance.com and graphed client side using the Dojo Chart widget. [...] [...] Frequent readers will recall that, a few months ago, I built a performance instrumentation package which supported the collection and aggregation of performance metrics from inside an end user’s browser. Timings are communicated up to a Rails app at aelite.ajaxperformance.com and graphed client side using the Dojo Chart widget. [...]

]]> By: Ajax Performance » WebWait http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-2154 Ajax Performance » WebWait Wed, 14 Feb 2007 05:35:25 +0000 http://www.ajaxperformance.com/?p=28#comment-2154 [...] As I’ve posted previously, collecting Ajax performance information directly within the browser is compelling and provides a level of insight that simply isn’t available with other techniques. It’s great to see so much focus on Ajax-aware performance testing these days. [...] [...] As I’ve posted previously, collecting Ajax performance information directly within the browser is compelling and provides a level of insight that simply isn’t available with other techniques. It’s great to see so much focus on Ajax-aware performance testing these days. [...]

]]> By: Alex Russell http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-63 Alex Russell Mon, 20 Nov 2006 22:17:57 +0000 http://www.ajaxperformance.com/?p=28#comment-63 Ryan: kinda. The network round-trip optimization only makes sense up to a point. Frankly, given the small number of files that are going to be "specialized" and given that they're gonna be cached, I'd make a build that includes everything up to, but not including, the svg/vml code. Yes, you'll still have one or two sync XHR calls to get the others, but I think you'll find it just much simpler a setup to maintain. I'll send you a build that does this in private mail. Regards Ryan: kinda. The network round-trip optimization only makes sense up to a point. Frankly, given the small number of files that are going to be “specialized” and given that they’re gonna be cached, I’d make a build that includes everything up to, but not including, the svg/vml code. Yes, you’ll still have one or two sync XHR calls to get the others, but I think you’ll find it just much simpler a setup to maintain.

I’ll send you a build that does this in private mail.

Regards

]]> By: Ryan Breen http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-62 Ryan Breen Mon, 20 Nov 2006 21:34:04 +0000 http://www.ajaxperformance.com/?p=28#comment-62 Alex, Any help would certainly be appreciated, and I will gladly replace my current build with an optimized build you provide, if it's not too much trouble. My goal was to package all necessary code into a single .js to reduce network round tripping, and I believe that this requires a separate build for svg and vml as the two appear to be mutually exclusive. Does this approach make sense? Ryan Alex,

Any help would certainly be appreciated, and I will gladly replace my current build with an optimized build you provide, if it’s not too much trouble.

My goal was to package all necessary code into a single .js to reduce network round tripping, and I believe that this requires a separate build for svg and vml as the two appear to be mutually exclusive. Does this approach make sense?

Ryan

]]> By: Alex Russell http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-61 Alex Russell Mon, 20 Nov 2006 20:55:21 +0000 http://www.ajaxperformance.com/?p=28#comment-61 Ryan: Thanks for the clarification. Let me know if I can be of assistance in getting you a build for use on your charting page. Regards Ryan: Thanks for the clarification. Let me know if I can be of assistance in getting you a build for use on your charting page.

Regards

]]> By: Ryan Breen http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-60 Ryan Breen Mon, 20 Nov 2006 20:45:56 +0000 http://www.ajaxperformance.com/?p=28#comment-60 Alex, I started a kitchen sink build for expediency and to set a worst case baseline for performance. My intention was not to set Dojo up to fail but to see how code changes or packaging optimizations impact performance. Even with such a ham-fisted approach, performance is actually very good, with a parse time of 55ms and a render time of 180ms, across all browsers. I will update the site with a more optimized lib, and I clarified the language of the original post to claim more responsibility for the 'robust girth.' Ryan Alex, I started a kitchen sink build for expediency and to set a worst case baseline for performance. My intention was not to set Dojo up to fail but to see how code changes or packaging optimizations impact performance.

Even with such a ham-fisted approach, performance is actually very good, with a parse time of 55ms and a render time of 180ms, across all browsers.

I will update the site with a more optimized lib, and I clarified the language of the original post to claim more responsibility for the ‘robust girth.’

Ryan

]]> By: Alex Russell http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-59 Alex Russell Mon, 20 Nov 2006 20:23:05 +0000 http://www.ajaxperformance.com/?p=28#comment-59 Ryan: If you're interested in real-world Dojo performance, why are you using a kitchen sink build for these tests? You can construct builds that match your use case much better and won't cost so much. It's frustrating to see a "benchmark" of Dojo that sets it up to fail when I'm sure you know that we provide tools for optimizing the very metrics that you're looking at. Regards Ryan: If you’re interested in real-world Dojo performance, why are you using a kitchen sink build for these tests? You can construct builds that match your use case much better and won’t cost so much. It’s frustrating to see a “benchmark” of Dojo that sets it up to fail when I’m sure you know that we provide tools for optimizing the very metrics that you’re looking at.

Regards

]]> By: Ryan Breen http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-57 Ryan Breen Mon, 20 Nov 2006 17:10:07 +0000 http://www.ajaxperformance.com/?p=28#comment-57 Start time is relative to the loading of aelite.js. The first stanza action performed by aelite is the setting of the start timestamp. Any event that happens in the page is timed against this start, so a start of 0 means that effectively no clock time passed between executing aelite.js and executing the first timer. Start time is relative to the loading of aelite.js. The first stanza action performed by aelite is the setting of the start timestamp. Any event that happens in the page is timed against this start, so a start of 0 means that effectively no clock time passed between executing aelite.js and executing the first timer.

]]> By: James http://www.ajaxperformance.com/2006/11/19/if-you-are-reading-this-post-you-are-contributing-to-a-benchmark/#comment-56 James Mon, 20 Nov 2006 16:32:19 +0000 http://www.ajaxperformance.com/?p=28#comment-56 I don't understand the number very well. The first number is suppored to be the start. The start of what? It's hard to beleive that some start time is 0 and on other is 5 seconds? I guess I don't understand what I'm seeing. I don’t understand the number very well.

The first number is suppored to be the start. The start of what? It’s hard to beleive that some start time is 0 and on other is 5 seconds?

I guess I don’t understand what I’m seeing.

]]>