richvdh
commented
6 years ago Empirically, no we haven't broken performance, since matrix.org is now using simplejson without a catastrophic decrease in performance.
I have spent some time profiling ujson, simplejson and json; the results look like this:
(In the above, simplejson uses simplejson.dumps; simplejson_static creates a static JSONEncoder and JSONDecoder and uses encode and decode).
Conclusions are:
- on the load (deserialisation) path,
simplejsonoutperformsujsonfor large objects and is comparable for small objects. Stockjsonis much slower than either. - on the dump (serialisation) path, the situation isn't as rosy - simplejson is approximately twice as slow as
ujson, and 1.5x as slow even as stockjson.
Despite that, I think we want to use simplejson anyway. The reasons for this are:
- I think it's important to use a single encoder/decoder consistently, to avoid disasters like the one we had with #3008 (where we were able to deserialise an event, but not serialise it again later).
ujsondoes not appear to be well-maintained. The bug we found was indeed fixed over a year ago, but that has yet to be released (and I am really not keen to depend on a git version of it, since we'd have to ship our own binaries for debian etc)- The benchmarks here don't show it, but for some configurations (such as
sort_keys=True, as used incanonicaljson),jsonis way slower thansimplejson. - For me,
simplejson's superiorloadperformance wins overjson's superiordumpperformance. We may also be able to push a few optimisations upstream (see https://github.com/simplejson/simplejson/pull/212, for example).
As part of this work, I've also discovered that canonicaljson is slow (4x slower than simplejson for canonicaljson 1.0.0, though this is reduced to 1.5x in canonicaljson 1.1.0).
And whet we'd be better off pinning against a non-broken version of ujson (as apparently the upstream git is fixed).
See https://github.com/matrix-org/synapse/pull/3008