views:

3789

answers:

5

Using groovy, would you expect better performance in terms of speed and memory overhead to read and query JSON vs XML?

+3  A: 

JSON is smaller and simpler than XML. I'd bet that JSON is faster to parse.

YAML would be faster still.

S.Lott
I thought YAML was a superset of JSON ... so if there is less to parse with JSON, wouldn't it be faster?
Anthony Cramp
See http://yaml.org/ YAML is different from JSON. More expressive and a tiny bit simpler to parse that JSON.
S.Lott
See http://redhanded.hobix.com/inspect/yamlIsJson.html All JSON is valid YAML, therefore YAML can be considered a superset of JSON.
Adam Lassek
No: YAML certainly will NOT be faster. It is more complicated, parser has to do more work. Chances are it'll be slower than what fastest xml parsers (see "Aalto") do.JSON implementations for Java can be faster than xml, but it depends more on processing model and implementation than data format.
StaxMan
@StaxMan: I'm sure that the YAML/JSON folks would strongly disagree on the "more complicated" issue. The parser is simpler, and preliminary results indicate that it is often faster. http://webignition.net/articles/xml-vs-yaml-vs-json-a-study-to-find-answers/. I don't understand "java faster than XML" since one's an imperative language and the other's just a representation of data.
S.Lott
I'm not sure about YAML versus JSON, but I'd be pretty confident that either of them would be faster to process than XML.I think StaxMan meant "JSON implementations for Java can be faster than FOR xml", but he can always correct me if I'm wrong.
Matt Passell
+1  A: 

XML has a bit more overhead than JSON because of the angle brackets and extra information and what not. Any good parser should be able to parse JSON faster than XML for this reason.

Terrapin
"bit more"? That's charitable. I find that a "boat-load more" is more accurate. Maybe I'm just looking at egregiously bad XML.
S.Lott
I think you're about right :)
Terrapin
Actually, core xml 1.0 does not have that much more that matters for _parsing_: just namespaces, linefeed normalization, and DTD entity handling (which is a big thing actually) if DTDs are used.It's all the other (optional) xml cruft that gets complicated; if you use XML Schema, DTD, XSLT etc.
StaxMan
+2  A: 

If speed was really an issue, I would rather use a java library to parse whatever I want than to rely on Groovy's implementation.

gizmo
+2  A: 

If it's the same schema and the same information the memory usage will be nearly the same. Performance should be negligible between the two.

Nelson
+1  A: 

I believe the performance difference would be undetectable to anything other than a profiler if the schema and data is the same. That said you could see a big difference if you used the wrong XML parser. In other words a SAX implementation could easily match or possibly outperform the JSON parsing. There are a lot of external factors to cinsider. If you want the true story throw both a JSON and a SAX parser at the same data/schema with no additional logic. The big savings come from the logic used to interpret the parse. It may be simpler to use a DOM or a pull parser depending on your reqs while SAx would cause an overly complicated non-performant solution. Also there are noticeable differences between parsers as well. Add in the variable of file size and you quickly loose scope of what you're actually measuring. Another example, if your XML includes DTD descriptions and entity references that must be resolved over the wire and your network connection has high latency then you could see improvements with JSON. It all boils down to what you are really trying to do.

Cliff