Update JSON response stringify for better performance

[feego]

Hi, I've been doing some profiling to a REST API I've been working on and noticed that, for large JSON responses, a lot of time was being spent stringifying the actual responses. After some digging, I found out that the performance of the native V8 JSON.stringify degrades very quickly when the method is called with more than 1 argument (the Javascript object to stringify itself), even if the other arguments are null or undefined.

I've done some simple but yet conclusive tests with JSON.stringify and got some results to share:

• Object to stringify: fathers.txt
• Script used:

// Copy pasted data into variable fathers.
var fathers = ....;

// Test 1.
var startTime = Date.now();
JSON.stringify(fathers, null, null);
console.log(Date.now() - startTime);
// Prints 215.

// Test 2.
startTime = Date.now();
JSON.stringify(fathers);
console.log(Date.now() - startTime);
// Prints 20.

Hapi is currently stringifying all JSON response objects calling JSON.stringify always with all the 3 arguments, even if the last 2 are null. I updated the JSON.stringify call in Hapi to use this last 2 arguments only when they have non falsy values.

[hueniverse]

Interesting. I don't mind the optimization but if should be implemented using an if statement, not apply. That should also fix the exception your code is throwing.

[feego]

Thanks, it's done.

[leesei]

I've made a jsPerf for this finding:
JSON.stringify() w/ and w/o param · jsPerf

I think it's a v8 bug, opened issue here.

[leesei]

It is confirmed by the v8 team that this is the expected behavior.
This v8 specific optimization LGTM.

[mcollina]

Passing here by change: you should use http://npm.im/fast-safe-stringify by @davidmarkclements. It "fixes" circular references and it is incredibly fast.

[davidmarkclements]

Just to clarify, it's not as fast as using JSON.stringify as-is, but as far as I know it's the fastest "safe stringifer" - particularly for large objects

fast-safe-stringify is 2x faster for small objects, and 6x faster for large objects than json-stringify-safe

If you have no concerns around circular references then to my knowledge, directly using JSON.stringify is as fast as you can get atm.

But yeah I noticed the same degradation with additional params, which led to the technique used in fast-safe-stringify

[mcollina]

Also there is a try catch, which is not needed with fast-safe-stringify
Il giorno ven 8 apr 2016 alle 19:28 David Mark Clements <
notifications@github.com> ha scritto:

Just to clarify, it's not as fast as using JSON.stringify as-is, but as
far as I know it's the fastest "safe stringifer" - particularly for large
objects

fast-safe-stringify is 2x faster for small objects, and 6x faster for
large objects than json-stringify-safe

If you have no concerns around circular reference then to my knowledge,
directly using JSON.stringify is as fast as you can get atm.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#3014 (comment)

[devinivy]

@mcollina That's actually a pretty good point– the try/catch deoptimizes that internal _streamify() function. If someone has the time, I'd be interested to see if breaking it out into a minimal function makes a difference.

[hueniverse]

Thanks but not going to add external deps.

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.