(using the Java 6 Rhino implementation) parsing of JSON messages. These
are several hundred results for the Google
Geo location service, which I though was good
sampling data. First
of all, JSON reduces bandwidth usage by more than 40% over XML use.
In terms of performance, I ran this multiple times, trying to
remember my statistics class.
On my laptop (a Windows/Solaris x86 @ 2.13GHz running Java 6 b90 with
no tuning) :
|Time to execute|
|Java hack||4||15 ms|
|JSON Java API||14||62 ms|
(Java 6 Rhino)
|Compiled JSON scripts
(Java 6 Rhino)
|STaX hack||18||265 ms|
My Java hack is the fastest but it’s a hack because it’s based
String manipulation (no parsing) and it stops on the first occurrence
a given sub-string (I don’t even check for result status in the
message). While this is not elegant code, all four implementations
provide the same results… The JSON Java API is pretty fast and the
difference with the Java hack is probably due to the fact that it does
full parsing of the message.
hack simply stops after it finds the data it was looking for (result
code and two coordinates). The XPath implementation uses two simple
XPath expressions (
and a simple
StringTokenizer to get the same
data. Be carefull in both cases to use the UTF-8 encoding as set in the
Google response file :
Java 6 Rhino-based implementations are an order of magnitude slower. This
is mainly due to everything remaining interpreted (no compilation to by-code).
Also, this use-case is evaluating each message three times. My implementation
is slower than using subsequent plain
calls. In both cases, the NetBeans
the CPU time (I’ve ran all my tests in the same run, so
100% for this specific test).
Searching for HotSpots shows the overhead of setting up compiled
Setting up the
ScriptContext is costly and
recycling it could be worthwhile (
15% gain of
the total time spent talking to Rhino).
Backtraces show the
as being much more costly when invoked from the
compiled version of
The only thing that can be done here is reduce the number of calls to
In the case of XPath, which I though was an elegant way to retrieve
data, the profiler shows
80% spent in JAXP’s
implementation of XPath (and
16% in getting
the data back from the database). Nothing I can do to improve things
Of course, in the context of Google’s GeoCoding service, these
performances numbers need to be put into perspective: I have 1.75
process each result and the worse result will still have plenty of time
to complete before my timer triggers the next call.
around can justify the use of JSON over XML. JSON also doesn’t
manipulate. XML can be more
verbose, but using XML and proper parsing (SAX, DOM, and now XPath or
STaX) is easy
and part of every JDK. JSON parsing tools (about a 80k jar
for JSON Java classes) are not. Maybe (yet another) good RFE for
But then again with E4X (not part of the Rhino Mustang implementation),
worlds are converging, maybe colliding.
Update 1:: If E4X is what you want, Phobos has full support for this
Update 2:: Google now has a short and simple CSV response format with only return code, coordinates and a new useful “precision” value.