JSON.stringify vs. devalue.uneval

[antonha]

I recently started running profiling (based on the V8 profiler in node). I decided to bench my site using apache-bench - and was able to max out CPU usage on one core for the svelte process (running adapter-node).

When doing this, I noticed that in the render_response function, about 80% of the CPU samples were in the uneval function of the devalue package. If my understanding is correct, this is for hydrating data to the client-side JS. The code to server-side render only seems to take up ~5% of the rendering time. My data was about ~200KB in JSON.

I've run some simple benchmarks comparing uneval and JSON.stringify using the benchmarking functionality in vitest:

import data from "large-file.json";
import {bench} from "vitest";
import {uneval} from "devalue";

bench("devalue.uneval", () => {
  uneval(data);
}, {time: 10_000, warmupTime: 1_000})

bench("json.stringify", () => {
  JSON.stringify(data);
}, {time: 10_000, warmupTime: 1_000})

Where the large file is this random big JSON file I found on github.

And got this output:

RUN  v0.33.0 /home/anton/dev/blunders/blunders-web

 ✓ src/str.bench.ts (2) 22713ms
     name                 hz      min     max     mean      p75     p99    p995    p999     rme  samples
   · devalue.uneval   3.6498   261.73  366.04   273.99   275.28  366.04  366.04  366.04  ±2.00%       37
   · json.stringify  12.9485  65.5212  228.60  77.2288  74.1546  213.53  228.60  228.60  ±4.90%      132   fastest


 BENCH  Summary

  json.stringify - src/str.bench.ts >
    3.55x faster than devalue.uneval

I.e. JSON.stringify could serialize the JSON 3.5x faster. The result will of course depend on size and shape of the input data.

Now, of course devalue has more functionality - it allows for futures, Maps, Sets, Dates etc. The question I would like to ask is if the extra functionality is worth the slowdown?

For my project, it is not - I fetch fairly large JSON structures from a backend API and use them for rendering - I don't need the Date etc. functionality. I suspect that this is a fairly common pattern, but there are surely other users that would rather have the uneval functionality. This could be a toggle, but that would of course bring complexity. Also, changing (back?) to only allowing JSON would break backwards compatibility.

While I'm no JS/node expert, I did try to optimize the uneval package a bit. I could get some small speedups in the range of ~10%, but making it compete with JSON.stringify feels unrealistic, since JSON.stringify can be implemented within the V8 engine. Might be that uneval could be as fast if it was instead implemented as native code with nodejs bindings? Not sure how this would impact e.g. cloudflare workers that don't have a full nodejs runtime.

P.S.

Thanks a lot for svelte-kit, I enjoy it immensely.