JSON.parse - performance & security

[billywhizz]

I've been doing some testing around building a low latency high volume
server and have come up against some interesting issues with
JSON.parse in node/v8.

While testing, i discovered that JSON.parse is actually pretty slow,
at least for what i am trying to do. As an example:

I am parsing this string into a JS object:

var orig = {
"u":1111111111,
"m":"2222222222",
"e":3333333333,
"t":1,
"a":44444444.44,
"p":55.55
};
var msg = JSON.stringify(orig);

The built in JSON.parse takes 16usec to parse this, compared to 9usec
for json-sans-eval (http://code.google.com/p/json-sans-eval/), 2
seconds for a custom regex parse, and 0.06 usec for the benchmark,
which just returns a hard coded new object.

Does anyone know where in the source for v8/node i can find what
JSON.parse actually does? I've had a quick scan through the code and i
think that v8 is actually compiling whatever you send to it and
returning the compiled object.That doesn't seem like a very efficient
solution to me.

Any thoughts?

if you want to test yourself, I can post some code up on github...

[billywhizz]

i've tested the three main js JSON parsers from the JSON website and
get the following average results on my setup:

v8 JSON.Parse = 16 usec
json-sans-eval = 10 usec
json-parse-state = 27 usec
json-parse = 12 usec

[Ciaran]

On Mon, Mar 1, 2010 at 9:49 PM, billywhizz <apjo...@gmail.com> wrote:
> i've tested the three main js JSON parsers from the JSON website and
> get the following average results on my setup:
>
> v8 JSON.Parse = 16 usec
> json-sans-eval = 10 usec
> json-parse-state = 27 usec
> json-parse = 12 usec

FWIW I ran into a similar (related?) issue the other night when
dealing with flickr's returned JSON. JSON.Parse is *validating*
(according to ES5's current specification). json-sans-eval for one
isn't validating, I imagine some of your time is going on that
validation :(

( Turns out that { a: "\'" } is very invalid in ES5 ...but allowed by
the JSON RFC's 'extensions' clause )

I still find this a bit weird, as I'd always written things to be
gracious in what they accept and strict in what they return, but since
ES5 is written by far smarter folks than I would ever claim to be I
have to assume I've missed the point ;)

-cj

[billywhizz]

only way to go if you want fast parsing is custom parsing and a
defined protocol really. using something like JSON/XML/any other
generic markup language is always going to be slower.

this kind of differences are important though if you want to build
fast servers that can actually handle traffic on those 50-100k
connections that node allows you to support... especially when there
is only one thread of execution. i'm working on something at the
moment on top of node.js that i'm hoping will be able to handle
50-100k journalled transactions per second (maybe even more depending
on hardware and code optimisations). that would be pretty f*ckin
cool....

On Mar 1, 9:55 pm, Ciaran <ciar...@gmail.com> wrote:

[Gabriel Farrell]

On Mon, Mar 1, 2010 at 4:49 PM, billywhizz <apjo...@gmail.com> wrote:
> i've tested the three main js JSON parsers from the JSON website and
> get the following average results on my setup:
>
> v8 JSON.Parse = 16 usec
> json-sans-eval = 10 usec
> json-parse-state = 27 usec
> json-parse = 12 usec

Have you looked at yajl (http://lloyd.github.com/yajl/)? I haven't
tried it, but there could be a notable difference, especially on
larger JSON strings, and it looks like bindings to Node are already
being worked on (http://bitbucket.org/nikhilm/yajl-js/).