4 ms·

JSON, XML performance

15 points by kowsik 17y ago

noss 17y ago
In my experience, that which kills "snappyness" for commercial sites is primary annoyingly slow industry standard ad- and traffic-tracking-systems, and secondary layout rendering issues due to complex css or silly number of images. (Lesson learned: make sure you can serve pages without ad and tracking scripts to show the customer that you are fast as hell, that it is their "money-maker dependencies" that kill snappiness) Javascript can often be hidden behind some user-initiated click, where it "feels" okay to have 1 or 2 sec of delay given that some feedback is given directly, such as changing the mouse pointer or the color of the button pressed. I wish github would let me be the initiator of more of their page updates, because those pages can be really slow to finish using my weaker machines.
- pjhyett 17y ago
  Could you specify which parts of GitHub you're referring to? We're always looking for way to improve the site.
dandelany 17y ago
Umm... Am I missing something? The blog post describes comparing XML parsing to JSON parsing, but that chart compares JSON parse time to XHR request time for that JSON file! The real chart he should be referring to is here: http://ejohn.org/apps/jsonvxml2/json-speeds.png http://ejohn.org/apps/jsonvxml2/json-speeds.png
- dandelany 17y ago
  actually, this one's better: http://ejohn.org/apps/jsonvxml/jsonvxml.png http://ejohn.org/apps/jsonvxml/jsonvxml.png
woadwarrior01 17y ago
I think the scenario described in the post might be deliberately contrived. JQuery uses window.eval ( http://dev.jquery.com/browser/trunk/jquery/src/ajax.js#L503 http://dev.jquery.com/browser/trunk/jquery/src/ajax.js#L503 ) to parse JSON, not Douglas Crockford's json.js. So, merely swapping XML with JSON shouldn't result in as much of a slow down (if not a speedup) as the graph tends to indicate.
- kowsik 17y ago
  http://www.json.org/json2.js http://www.json.org/json2.js and here's the appropriate comment: // In the third stage we use the eval function to compile the text into a // JavaScript structure. The '{' operator is subject to a syntactic ambiguity // in JavaScript: it can begin a block or an object literal. We wrap the text // in parens to eliminate the ambiguity. So um, json.js does use eval, same as jQuery. On http://www.pcapr.net http://www.pcapr.net, we use tons of javascript and I've noticed returning "large" JSON arrays makes quite a few different browsers croak.
- kowsik 17y ago
  Also read this about native JSON: http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/ http://blog.mozilla.com/webdev/2009/02/12/native-json-in-fir... Which could make the speed comparable, but just on FF31

15 points by kowsik 17y ago

noss 17y ago

In my experience, that which kills "snappyness" for commercial sites is primary annoyingly slow industry standard ad- and traffic-tracking-systems, and secondary layout rendering issues due to complex css or silly number of images. (Lesson learned: make sure you can serve pages without ad and tracking scripts to show the customer that you are fast as hell, that it is their "money-maker dependencies" that kill snappiness) Javascript can often be hidden behind some user-initiated click, where it "feels" okay to have 1 or 2 sec of delay given that some feedback is given directly, such as changing the mouse pointer or the color of the button pressed. I wish github would let me be the initiator of more of their page updates, because those pages can be really slow to finish using my weaker machines.

pjhyett 17y ago
Could you specify which parts of GitHub you're referring to? We're always looking for way to improve the site.

dandelany 17y ago

Umm... Am I missing something? The blog post describes comparing XML parsing to JSON parsing, but that chart compares JSON parse time to XHR request time for that JSON file! The real chart he should be referring to is here: http://ejohn.org/apps/jsonvxml2/json-speeds.png http://ejohn.org/apps/jsonvxml2/json-speeds.png

dandelany 17y ago
actually, this one's better: http://ejohn.org/apps/jsonvxml/jsonvxml.png http://ejohn.org/apps/jsonvxml/jsonvxml.png

woadwarrior01 17y ago

I think the scenario described in the post might be deliberately contrived. JQuery uses window.eval ( http://dev.jquery.com/browser/trunk/jquery/src/ajax.js#L503 http://dev.jquery.com/browser/trunk/jquery/src/ajax.js#L503 ) to parse JSON, not Douglas Crockford's json.js. So, merely swapping XML with JSON shouldn't result in as much of a slow down (if not a speedup) as the graph tends to indicate.

kowsik 17y ago
http://www.json.org/json2.js http://www.json.org/json2.js and here's the appropriate comment: // In the third stage we use the eval function to compile the text into a // JavaScript structure. The '{' operator is subject to a syntactic ambiguity // in JavaScript: it can begin a block or an object literal. We wrap the text // in parens to eliminate the ambiguity. So um, json.js does use eval, same as jQuery. On http://www.pcapr.net http://www.pcapr.net, we use tons of javascript and I've noticed returning "large" JSON arrays makes quite a few different browsers croak.
kowsik 17y ago
Also read this about native JSON: http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/ http://blog.mozilla.com/webdev/2009/02/12/native-json-in-fir... Which could make the speed comparable, but just on FF31