Comments for Census 2: More Than Just A Pretty Graph
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!
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
It's a little strange to see the benchmarks game linked in this context, seems like SunSpider would be more to the point.
Here is my sample: #
1 10 100 250 <!--assets/1_million.csv-->
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.
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
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
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