diff --git a/bench/benchmark.org b/bench/benchmark.org index b0c5b73..463075e 100644 --- a/bench/benchmark.org +++ b/bench/benchmark.org @@ -25,8 +25,9 @@ Here's a way to model this in PSYC: ** A message with JSON-unfriendly characters This message contains some characters which are -impractical to encode in JSON. Let's see how much -performance impact this has. +impractical to encode in JSON. We should probably +put a lot more inside to actually see an impact +on performance. #+INCLUDE: packets/json-unfriendly.xml src xml #+INCLUDE: packets/json-unfriendly.json src js @@ -34,7 +35,8 @@ performance impact this has. ** A message with XML-unfriendly characters Same test with characters which aren't practical -in the XML syntax. +in the XML syntax, yet we should put more of +them inside. #+INCLUDE: packets/xml-unfriendly.xml src xml #+INCLUDE: packets/xml-unfriendly.json src js @@ -170,6 +172,49 @@ not performed. These tests were performed on a 2.53 GHz Intel(R) Core(TM)2 Duo P9500 CPU. +* Criticism + +Are we comparing apples and oranges? Yes and no, depends on what you +need. XML is a syntax best suited for complex structured data in +well-defined formats - especially good for text mark-up. JSON is a syntax +intended to hold arbitrarily structured data suitable for immediate +inclusion in javascript source codes. The PSYC syntax is an evolved +derivate of RFC 822, the syntax used by HTTP and E-Mail, and is therefore +limited in the kind and depth of data structures that can be represented +with it, but in exchange it is highly performant at doing just that. +In fact we are looking into suitable syntax extensions to represent +generic structures and semantic signatures, but for now PSYC only +provides for simple typed values and lists of typed values. + +Another aspect is the availability of these formats for spontaneous +use. You could generate and parse JSON yourself but you have to be +careful about escaping. XML can be rendered manually if you know your +data will not break the syntax, but you can't really parse it without +a bullet proof parser. PSYC is easy to render and parse yourself for +simple tasks, as long as your body does not contain "\n|\n" and your +variables do not contain newlines. + +After all it is up to you to find out which format fulfils your +requirements the best. We use PSYC for the majority of messaging where +JSON and XMPP aren't efficient and opaque enough, but we employ XML and +JSON as payloads within PSYC for data that doesn't fit the PSYC model. +For some reason all three formats are being used for messaging, although +only PSYC was actually designed for that purpose. + +* Caveats + +In every case we'll compare performance of parsing and re-rendering +these messages, but consider also that the applicative processing +of an XML DOM tree is more complicated than just accessing +certain elements in a JSON data structure or PSYC variable +mapping. + +For a speed check in real world conditions which also consider the +complexity of processing incoming messages we should compare +the performance of a chat client using the two protocols, +for instance by using libpurple with XMPP and PSYC accounts. +To this purpose we first need to integrate libpsyc into libpurple. + * Conclusions The Internet has developed two major breeds of protocol formats. @@ -187,46 +232,6 @@ combines the compactness and efficiency of binary protocols with the extensibility of text-based protocols and still provides for enough data structuring to rarely require the use of other data formats. -* Criticism - -Are we comparing apples and oranges? Yes and no, depends on what you -need. XML is a syntax best suited for complex structured data in -well-defined formats - especially good for text mark-up. JSON is a syntax -intended to hold arbitrarily structured data suitable for immediate -inclusion in javascript source codes. The PSYC syntax is an evolved -derivate of RFC 822, the syntax used by HTTP and E-Mail, and is therefore -limited in the kind and depth of data structures that can be represented -with it, but in exchange it is highly performant at doing just that. - -So it is up to you to find out which format fulfils your -requirements the best. We use PSYC for the majority of messaging where -JSON and XMPP aren't efficient and opaque enough, but we employ XML and -JSON as payloads within PSYC for data that doesn't fit the PSYC model. -For some reason all three formats are being used for messaging, although -only PSYC was actually designed for that purpose. - -Another aspect is the availability of these formats for spontaneous -use. You could generate and parse JSON yourself but you have to be -careful about escaping. XML can be rendered manually if you know your -data will not break the syntax, but you can't really parse it without -a bullet proof parser. PSYC is easy to render and parse yourself for -simple tasks, as long as your body does not contain "\n|\n" and your -variables do not contain newlines. - -* Caveats - -In every case we'll compare performance of parsing and re-rendering -these messages, but consider also that the applicative processing -of an XML DOM tree is more complicated than just accessing -certain elements in a JSON data structure or PSYC variable -mapping. - -For a speed check in real world conditions which also consider the -complexity of processing incoming messages we should compare -the performance of a chat client using the two protocols, -for instance by using libpurple with XMPP and PSYC accounts. -To this purpose we first need to integrate libpsyc into libpurple. - * Futures After a month of development libpsyc is already performing pretty @@ -253,6 +258,9 @@ specialized parsers and renderers to be provided. * Appendix ** Tools used +This document and its benchmarks are distributed with libpsyc. +See http://about.psyc.eu/libpsyc on how to obtain it. + *** libpsyc : make bench