With a well written parser, XML and JSON will have more or less the same timing. You can have a slow JSON parser, and a fast XML parser.
Perhaps a bit slower for XML because the syntax is more complex than JSON's.
But the bottleneck will be mostly reading from the hard drive, not parsing the content.
We used JSON for the Client/Server of our ORM, for several reasons (but you'll find others, I don't want to troll here, just speak from our little experiment):
- Like XML, it's a text-based, human-readable format for representing simple data structures and associative arrays (called objects);
- It's easier to read (for both human beings and machines), quicker to implement, and usually smaller in size than XML;
- It's a very efficient format for data caching;
- Its layout allows to be rewritten in place into individual zero-terminated UTF-8 strings, with almost no wasted space: this feature is used for blazzling fast JSON to text conversion of the tables results, with no memory allocation nor data copy;
- It's natively supported by the JavaScript language, making it a perfect serialization format in any AJAX (i.e. Web 2.0) application;
- The JSON format is specified in a well known and simple RFC;
- The default text encoding for both JSON and our ORM is UTF-8, which allows the full Unicode charset to be stored and communicated;
- It is the default data format used by ASP.NET AJAX services created in Windows Communication Foundation (WCF) since .NET framework 3.5; so it's Microsoft officialy "ready";
- For binary blob transmission, there is no CDATA as in XML. So we simply encode the binary data as hexadecimal or Base64 (uses less space) inside a JSON string.
About parsing speed, you could take a look at our in-place parser and JSON writer from SQLite3 results. It was very optimized for speed, and fast it is. We wrote a simple but efficient JSON serialization for any TPersistent, including collections. We just add a dynamic array JSON serializer, which is also very fast.
Additional note:
All those parsers differ from the one you mentioned because they parse the JSON content and format it as text inside the input buffer: there is no memory allocation made during parsing, so it should be faster than other solutions. Text content is unescaped, fields are #0 ended, and a pointer to the beginning of the text is computed. So to access a value, you just use the pointer to get the data. It usually parses some MB of JSON content with no time.
Also take a look at the JSON parser embedded in DWS. The author claimed it was fast. But still allocated a memory block for each object.
