fast-stable-stringify v1.0.0

fast-stable-stringify

Notice: The License of this repository has been changed from GPL-3.0 to MIT as of 2017-08-25. All following commits will fall under the MIT license.

The test only succeeds when mine is faster than substack's in a particular browser.

The most popular repository providing this feature is substack's json-stable-stringify. The intent if this library is to provide a faster alternative for when performance is more important than features. It assumes you provide basic javascript values without circular references, and returns a non-indented string.

It currently offers a performance boost in popular browsers of about 40%. See the comparsion table below.

Usage:

var stringify = require('fast-stable-stringify');
stringify({ d: 0, c: 1, a: 2, b: 3, e: 4 }); // '{"a":2,"b":3,"c":1,"d":0,"e":4}'

Just like substack's, it does:

• handle all variations of all basic javascript values (number, string, boolean, array, object, null, Date)
• handle undefined and function in the same way as JSON.stringify
• not support ie8 (and below) with complete certainty.

Unlike substack's, it does:

• not implement the 'replacer' or 'space' arguments of the JSON.stringify method
• not check for circular references

Test results

Tested validity (answer equal to substack's) and benchmark (faster than substack's). A test passes only if it has the same output as substack's but is faster (as concluded by benchmark.js).

To (hopefully) prevent certain smart browsers from concluding the stringification is not necessary because it is never used anywhere, I summed up all the lengths of the resulting strings of each benchmark contestant and printed it along with the result data.

Latest interpreted result

See caniuse browser usage for the 'most popular browsers'.

Click the build status badge to view the original output.

Disclaimer: the more I test the more I realize how many factors actually affect the outcome. Not only the browser and browser version, but particularly the json content and a random factor in every test run. Outcomes may sometimes vary more than 10% between tests, despite my attempt to reduce this by increasing the sample size to 2.5 times. Nevertheless, the overall picture typically still holds.

JSON.stringify has been added for reference. In general, aside from the cases where you need the guarantee of a stable result, I would recommend against using this library, or any stable stringification library for that matter.

faster-stable-stringify has been added for comparison. It seems it does not work in IE 9 to 11 without a polyfill solution for WeakMap. It is displayed as somewhat slower, but as I decided on the JSON input to test and develop against, this result may be somewhat biased. In some test runs, faster-stable-stringify will be faster in a browser. In fact, it is consistently somewhat faster in the Mobile Safari 10.

Note about string escaping

The original implementation was with regexp. A pull request showed a literal string approach that was faster in some browsers. Other libraries would just use JSON.stringify. After a speed comparison between all three methods, it became clear that native JSON.stringify is generally much faster in string escaping than both these methods, even in the IE legacy browsers. The browsers that do not have JSON.stringify are not offered for test automation, and when looking at the usage percentage of such browsers I no longer see a reason to not use JSON.stringify.

Therefore, the exposed regexp and string are removed from the API. If you still need this functionality, I simply encourage you to use JSON.stringify.

Running tests

It runs karma-benchmark tests now. For testing in node, do:

npm test

This requires saucelabs credentials in your env. That, or edit the karma.conf.js to your liking.

Running this test will cause files in ./results/libs/ to update. Run npm run table to get a pretty md table of the results.