Stupendous stuff Alex. Having a tool which reports back its results for later analysis is indeed awesome. Can the test suite be invoked on a headless machine running Selenium RC?

I was looking at the descriptions of the XSLT and JSON to HTML tests and was wondering a few things. In the case of XSLT the time taken to retrieve the XSLT is included in the test, however, that can also be included as a string in the JavaScript code so there is no overhead of the extra request. In many cases XSLT is converted to a JavaScript string in a build process to avoid the second requets.

Also, in the JSON to HTML description it says "This method is relatively parsimonious with network resources due to the reduced amount of encoding cruft inherent in JSON versus HTML or XML." yet that all depends on how you write your XML. Saying that { person : { name : "Luke", zip_code : "90210" } has less cruft than is pretty misleading.

Otherwise, I am very happy to see the inclusion of XSLT and it was something that I was going to add onto James' work myself!

Hi Dave:

You're right that I could inline the XSLT into the served page, but I'm not sure that it would be representative. Part of the performance advantage of XSLT is that the XSLT doc can be cached across page views whereas the data might change. This allows formatting, which might otherwise balloon the size of content, to be factored out and served off of CDNs. It's true that in this case we're requesting it synchronously, and that's not representative. It is, however, cached across page views which would not be the case if it were served inline.

As for the size of XML vs. JSON, even a smaller XML syntax which is still semantically meaningful would still be larger than the comprable JSON. I'll leave this as an exercise to you. I do plan on adding a terser XML format (the current one is an artifact of the original Census app), but it'll still be bigger. By how much is an important question, though.

Regards

> And should we really pay any attention to how any > JS VM does on synthetic language benchmarks?

It's a little strange to see the benchmarks game linked in this context, seems like SunSpider would be more to the point.

It is recommended by Adobe to use Remoting for more than 1000 rows. There are tons of Flex paging routines on the net, but mostly paging is done on the client making it super fast. I've create a sample flex app to bring back a 'static' csv file (1k,10k,100k,250k) with httpservice and it can load 10k csv file in 60ms and parse it in 15ms.

Here is my sample: #

1 10 100 250 <!--assets/1_million.csv-->

its great such benchmarking is done, but pleaaase provide a summary, most people are not interested in the technology/metholodgy or what keeps those tests running, just say: blabla results: Flex is faster than AJAX on IE + Opera, but not on FF

There is no single finished graph or image in this post, and the only image links to dojofoundation, very helpful.

What i learned here: there are several technologies, but no idea which is best/good in which scenario, and running those tests on my machine, while there is emul and whatnot running will not provide any reliable data.

@Alex: yeah, go ahead and add me, I'll add it when I have a chance.

grosser:

The problem, until we get the AppEngine reporting back-end done, is that it's not that simple. As with most benchmarks, having one big headline number is perhaps the simplest way to get your benchmark to tell lies (even when that's totally unintentional).

This benchmark doesn't output a single big number because doing so wouldn't be honest. Numbers without context are lies waiting to be repeated.

I've fixed the link from the image. Sorry about that!

Regards

This is great news. I will have to take a close look at it.

Note that BlazeDS and I assume LCDS as well do bundle HTTP requests using an unspecified heuristics(seems to depend on the time between requests).

This might work very well to get better benchmarks numbers, but in practice it might not be that useful because currently one cannot influence the heuristics used, because it's done in native code.

Regards, Markus

Kris:

So I'd love to add a ServiceStore test. The overhead of Item wrapping in IFRS and even QRS has bugged me for some time, so showing how SS or JRS stack up would be a huge boon to the test suite. I can add you to the project if you like.

Regards

FWIW, for widgets (like the grid) that make extensive use of getValue calls, the ServiceStore/JsonRestStore tends to be much faster, especially compared to the ItemFileReadStore/ItemFileWriteStore and probably a lot faster than QueryReadStore as well (although QRS might be faster on actual data parsing times, not sure). Using those stores might make Dojo look a little better.