12 ms·

How we made JSON.stringify more than twice as fast

458 points by emschwartz 1y ago

hinkley 1y ago
JSON encoding is a huge impediment to interprocess communication in NodeJS. Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main thread. I’ve seen people stringify arrays one entry at a time. Sounds like maybe they are doing that internally now. If anything I would encourage the V8 team to go farther with this. Can you avoid bailing out for subsets of data? What about the CString issue? Does this bring faststr back from the dead?
- jcdavis 1y ago
  Based off of my first ever forays into node performance analysis last year, JSON.stringify was one of the biggest impediments to just about everything around performant node services. The fact that everyone uses stringify to for dict keys, the fact that apollo/express just serializes the entire response into a string instead of incrementally streaming it back (I think there are some possible workarounds for this, but they seemed very hacky) As someone who has come from a JVM/go background, I was kinda shocked how amateur hour it felt tbh.
  - MehdiHK 1y ago
    > JSON.stringify was one of the biggest impediments to just about everything around performant node services That's what I experienced too. But I think the deeper problem is Node's cooperative multitasking model. A preemptive multitasking (like Go) wouldn't block the whole event-loop (other concurrent tasks) during serializing a large response (often the case with GraphQL, but possible with any other API too). Yeah, it does kinda feel like amateur hour.
    - Rohansi 1y ago
      That's not really a Node problem but a JavaScript problem. Nothing about it was built to support parallel execution like Go and other languages. That's why they use web workers, separate processes, etc. to make use of more than a single core. But then you'll probably be dependent on JSON serialization to send data between those event loops.
      - miroljub 1y ago
        > That's not really a Node problem but a JavaScript problem. Nowadays Node is JavaScript. They are the guys driving JavaScript standards and new features for a decade or so. Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ...
        promiseofbeans 1y ago
        I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server. Yes, there have been a lot of advances in modern JS for things like atomics and other fun memory stuff, but that's just the natrual progression for a language as popular as JS. The 3 main JS engines are still developed primarily for web browsers, and web developers are the primary audience considered in ES language discussions (although I'll concede that in recent years server runtimes have been considered more and more)
        coldtea 1y ago
        >I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server. Clients are 90% still v8, so hardly different than Node.
        jerf 1y ago
        "Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ..." In principle perhaps not. In practice it is abundantly clear now from repeated experience that trying to retrofit such things on to a scripting language that has been single-threaded for decades is an extremely difficult and error-prone process that can easily take a decade to reach production quality, if indeed it ever does, and then take another decade or more to become something you can just expect to work, expect to find libraries that use properly, etc. I don't think it's intrinsic to scripting languages. I think someone could greenfield one and have no more problems with multithreading than any other language. It's trying to put it into something that has been single-threaded for a decade or two already that is very, very hard. And to be honest, given what we've seen from the other languages that have done this, I'd have a very, very, very serious discussion with the dev team as to whether it's actually worth it. Other scripting languages have put a lot of work into this and it is not my perception that the result has been worth the effort.
    - gwbas1c 1y ago
      > Yeah, it does kinda feel like amateur hour. NodeJS is intended for IO-heavy workloads. Specifically, it's intended for workloads that don't benefit from parallel processing in the CPU. This is because Javascript is strictly a single-threaded language; IE, it doesn't support shared access to memory from multiple threads. (And this is because Javascript was written for controlling a UI, and historically UI is all handled on a single thread.) If you need true multithreading, there are plenty of languages that support it. Either you picked the wrong language, or you might want to consider creating a library in another language and calling into it from NodeJS.
      - MehdiHK 1y ago
        > If you need true multithreading I didn't say multithreading anywhere. Mutitasking (concurrency) != Multithreading. You can do pre-emptive concurrency with a single thread in other runtimes, where each task gets a pre-defined amount of CPU time slice, that solves fair scheduling for both IO and CPU-bound workloads. Nobody is supposed to pick NodeJS for CPU-bound workload, but you cannot escape JSON parse/stringify event-loop blocking in practice (which is CPU-bound).
  - hinkley 1y ago
    > Based off of my first ever forays into node performance analysis last year, JSON.stringify was one of the biggest impediments to just about everything around performant node services Just so. It is, or at least can be, the plurality of the sequential part of any Amdahl's Law calculation for Nodejs. I'm curious if any of the 'side effect free' commentary in this post is about moving parts of the JSON calculation off of the event loop. That would certainly be very interesting if true. However for concurrency reasons I suspect it could never be fully off. The best you could likely do is have multiple threads converting the object while the event loop remains blocked. Not entirely unlike concurrent marking in the JVM.
  - dmit 1y ago
    Node is the biggest impediment to performant Node services. The entire value proposition is "What if you could hire people who write code in the most popular programming language in the world?" Well, guess what
    - hinkley 1y ago
      Nodejs will never be as bad as VB was.
      - jk3000 1y ago
        More or less accidentally I turned a simple Excel spreadsheet into a sizable data management system. Once you learn where the bottlenecks are, it is surprising how fast VB is nowadays.
      - schrodinger 1y ago
        Low bar!
      - germandiago 1y ago
        I know Javascript is fast but... I cannot go with such a messy ecosystem. I find Python highly preferrable for my backend code for more or less low and middle traffic stuff. I know Python is not that good deployment-wise, but the language is really understandable, I have tools for every use case, I can easily provide bindings from C++ code and it is a joy to work with. If on top of that, they keep increasing its performance, I think I will stick to it for lots of backend tasks (except for high performance, where I have lately been doing with C++ and Capnproto RPC for distributed stuff).
        m-schuetz 1y ago
        It comes down to language preferences. I find Python to be the worst thing computer science has to offer. No nested scoping in functions, variables leak through branches and loops due to lack of scopes, no classic for loops, but worst of all, installing python packages and frameworks never ever goes smoothly. I would like to love Jupyter notebooks because Notebooks are great for prototyping, but Jupyter and Python plotting libs are so clunky and slow, I always have to fall back to Node or writing a web page with JS and svg for plotting and prototyping.
  - deleted 1y ago
    [deleted]
- brundolf 1y ago
  Yeah. I think I've only ever found one situation where offloading work to a worker saved more time than was lost through serializing/deserializing. Doing heavy work often means working with a huge set of data- which means the cost of passing that data via messages scales with the benefits of parallelizing the work.
  - hinkley 1y ago
    I think the clues are all there in the MDN docs for web workers. Having a worker act as a forward proxy for services; you send it a URL, it decides if it needs to make a network request, it cooks down the response for you and sends you the condensed result. Most tasks take more memory in the middle that at the beginning and end. And if you're sharing memory between processes that can only communicate by setting bytes, then the memory at the beginning and end represents the communication overhead. The latency. But this is also why things like p-limit work - they pause an array of arbitrary tasks during the induction phase, before the data expands into a complex state that has to be retained in memory concurrent with all of its peers. By partially linearizing you put a clamp on peak memory usage that Promise.all(arr.map(...)) does not, not just the thundering herd fix.
- dwattttt 1y ago
  Now to just write the processing code in something that compiles to WebAssembly, and you can start copying and sending ArrayBuffers to your workers! Or I guess you can do it without the WebAssembly step.
  - hinkley 1y ago
    A JSON.toBuffer would be another good addition to V8. There are a couple code paths that look like they might do this, but from all accounts it goes Object->String->Buffer, and for speed you want to skip the intermediate.
    - dwattttt 1y ago
      I was actually imagining skipping the Object step; if you go from wire -> buffer, and only ever work on it in buffer form (i.e. in WebAssembly, in a language more amenable to working on buffers/bytes), you skip needing the Object -> JSON step. Notwithstanding whatever you need to do in the wire -> buffer step.
      - hinkley 1y ago
        Working with bytes in JS is still gross and I wouldn’t wish it on my worst enemy. Like I said, if you had a way to automate it, it wouldn’t be so bad.
- nijave 1y ago
  Same problem in Python. It'd be nice to have good/efficient IPC primitives with higher level APIs on top for common patterns
- userbinator 1y ago
  You mean: > JSON encoding is a huge impediment to communication I wonder how much computational overhead JSON'ing adds to communications at a global scale, in contrast to just sending the bytes directly in a fixed format or something far more efficient to parse like ASN.1.
  - hinkley 1y ago
    No. Because painful code never gets optimized as much as less painful code. People convince themselves to look elsewhere, and an incomplete picture leads to local optima.
    - hinkley 1y ago
      BTW, I often shorthand this as, "I'm not so much better [at optimization] as I am more stubborn." The number of times I've gone in looking for 10%, backed out a bit and rearranged the code first to find 25%, better maintainability, and space for a feature that marketing has been bitching about for three years and development keeps insisting we cannot do in any reasonable amount of time? Probably averages out to at least three times per employer, which is a good number of miracles to perform.
- tgv 1y ago
  > If anything I would encourage the V8 team to go farther with this. That feels the wrong way to go. I would encourage the people that have this problem to look elsewhere. Node/V8 isn't well suited to backend or the heavier computational problems. Javascript is shaped by web usage, and it will stay like that for some time. You can't expect the V8 team to bail them out. The Typescript team switched to Go, because it's similar enough to TS/JS to do part of the translation automatically. I'm no AI enthousiast, but they are quite good at doing idiomatic translations too.
  - com2kid 1y ago
    > Node/V8 isn't well suited to backend Node was literally designed to be good for one thing - backend web service development. It is exceptionally good at it. The runtime overhead is tiny compared to the JVM, the async model is simple as hell to wrap your head around and has a fraction of the complexity of what other languages are doing in this space, and Node running on a potato of a CPU can handle thousands of requests per second w/o breaking a sweat using the most naively written code. Also the compactness of the language is incredible, you can get a full ExpressJS service up and running, including auth, in less than a dozen lines of code. The amount of magic that happens is almost zero, especially compared to other languages and frameworks. I know some people like their magic BS (and some of the stuff FastAPI does is nifty), but Express is "what you see is what you get" by default. > The Typescript team switched to Go, because it's similar enough to TS/JS to do part of the translation automatically. The TS team switched to go because JS is horrible at anything that isn't strings or doubles. The lack of an int type hinders the language, so runtimes do a lot of work to try and determine when a number can be treated like an int. JS's type system is both absurdly flexible and also limiting. Because JS basically allows you to do anything with types, Typescript ends up being one of the most powerful type systems that has seen mass adoption. (Yes other languages have more powerful type systems, but none of them have the wide spread adoption TS does). If I need to model a problem domain, TS is an excellent tool for doing so. If I need to respond to thousands of small requests, Node is an excellent tool for doing so. If I need to do some actual computation on those incoming requests, eh, maybe pick another tech stack. But for the majority of service endpoints that consist of "get message from user, query DB, reformat DB response, send to user"? Node is incredible at solving that problem.
- deadbabe 1y ago
  When it comes time to do serious work in Node, that's when you start using TypedArrays and SharedArrayBuffers and work with straight binary data. stringifying is mostly for toy apps and smaller projects.
  - hinkley 1y ago
    If I took all the coworkers I’ve had in 30 years of coding whom I could really trust with the sort of bit fiddling array buffers, I could populate maybe two companies and everyone else would be fucked. TypedArray is a toy. Very few domains actually work well with this sort of data. Statistics, yes. Games? Do all the time, but also games: are full of glitches used by speed runners, due to games playing fast and loose to maintain an illusion they are doing much more per second than they should be able to. DataView is a bit better. I am endlessly amazed at how many times I managed to read people talk about TypedArrays and SharedByteArrays before I discovered that DataView exists and has existed basically forever. Somebody should have mentioned it a lot, lot sooner.
    - deadbabe 1y ago
      DataView has a lot of overhead. Just do it raw.
- zamalek 1y ago
  > Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main thread. Why not use structuredClone to communicate with the worker? So long as your object upholds all the rules you can pass it into postMessage directly.
  - hinkley 1y ago
    Structured clone only gets you a new object in this heap, not a new object in an isolate. You’re still doing stringify/parse under the hood every time you sendMessage.
    - zamalek 1y ago
      postMessage uses it transparently: https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
      - hinkley 1y ago
        So I wonder if any of these improvements could be applied to structuredClone. Benchmarks aren’t showing structuredClone favorably versus JSON round tripping. Likely because JSON-compatible data structures are less complex than clonable data. I suspect with this change JSON will now be faster than structuredClone.
        zamalek 1y ago
        > Benchmarks aren’t showing structuredClone favorably versus JSON round tripping. Which ones? Structured clone seems to be approximately the same as FF according to this (structuredClone is slightly faster on my machine, probably margin of error): https://measurethat.net/Benchmarks/Show/23052/0/structuredclone-vs-jsonparse-jsonstringify https://measurethat.net/Benchmarks/Show/23052/0/structuredcl... (Linux: FF 141, Chromium 138).
- cogman10 1y ago
  It's a major problem for JVM performance as well. Json encoding is simply fundamentally an expensive thing to do. One thing that improves performance for the JVM that'd be nice to see in node realm is that JSON serialization libraries can stream out the serialization. One of the major costs of JSON is the memory footprint. Strings take up a LOT more space in memory than a regular object does. Since the JVM typically only uses JSON as a communication protocol, streaming it out makes a lot of sense. The IO (usually) takes long enough to give a CPU reprieve while simultaneously saving memory.
MutedEstate45 1y ago
I really like seeing the segmented buffer approach. It's basically the rope data structure trick I used to hand-roll in userland with libraries like fast-json-stringify, now native and way cleaner. Have you run into the bailout conditions much? Any replacer, space, or custom .toJSON() kicks you back to the slow path?
jonas21 1y ago
The part that was most surprising to me was how much the performance of serializing floating-point numbers has improved, even just in the past decade [1]. [1] https://github.com/jk-jeon/dragonbox?tab=readme-ov-file#performance https://github.com/jk-jeon/dragonbox?tab=readme-ov-file#perf...
- jameshart 1y ago
  Roundtripping IEEE floating point values via conversion to decimal UTF-8 strings and back is a ridiculously fragile process, too, not just slow. The difference between which values are precisely representable in binary and which are precisely representable in decimal means small errors can creep in.
  - gugagore 1y ago
    You don't have to precisely represent the float in decimal. You just have to have each float have a unique decimal representation, which you can guarantee if you include enough digits: 9 for 32-bit floats, and 17 for 64-bit floats. https://randomascii.wordpress.com/2012/02/11/they-sure-look-equal/ https://randomascii.wordpress.com/2012/02/11/they-sure-look-...
    - jameshart 1y ago
      And you need to trust that whoever is generating the JSON you’re consuming, or will consume the JSON you generate, is using a library which agrees about what those representations round to.
      - jk-jeon 1y ago
        Note that the consumer side doesn't really have a lot of ambiguity. You just read the number, compute its precise value as written, round it to the closest binary representation with banker's rounding. You do anything other than this only under very special circumstances. Virtually all ambiguity lies on the producer side, which can be cleared out by using any of the formatting algorithms with the roundtripping-guarantee. EDIT: If you're talking about decimal->binary->decimal round-tripping, it's a completely different story though.
iouser 1y ago
Did you run any tests/regressions against the security problems that are common with parsers? Seems like the solution might be at risk of creating CVEs later
- rpearl 1y ago
  ...Do you think that v8 doesn't have tests for what might be one of the most executed userspace codepaths in the world?
taeric 1y ago
I confess that I'm at a bit of a loss to know what sort of side effects would be common when serializing something? Is there an obvious class of reasons for this that I'm just accidentally ignoring right off?
- vinkelhake 1y ago
  A simple example is `toJSON`. If an object defines that method, it'll get invoked automatically by JSON.stringify and it could have arbitrary side effects. I think it's less about side effects being common when serializing, just that their fast path avoids anything that could have side effects (like toJSON). The article touches briefly on this.
  - taeric 1y ago
    Right, I get that you could define something to have side effects. My question is why would you? What are some expected visible side effects of converting something to json? That said, I see that they called it out as you say, now. When I first read it, I thought they watched for side effects. I'm assuming they have an allow list on all standard types. The date types, in particular, often have a toJson that seems like it should still be used? (Or am I wrong on that, too? :D )
- kevingadd 1y ago
  Calling a property getter can have side effects, so if you serialize an object with a getter you have to be very cautious to make sure nothing weird happens underneath you during serialization. People have exploited this sort of side effect to get bug bounties before via type confusion attacks, iirc.
  - taeric 1y ago
    Right, I get how you could make something that would cause issues. I'm curious why you would want to? :D
    - kevingadd 1y ago
monster_truck 1y ago
I don't think v8 gets enough praise. It is fucking insane how fast javascript can be these days
- andyferris 1y ago
  Yeah, it is quite impressive! It's a real example of "you can solve just about anything with a billion dollars" though :) I'd prefer JavaScript kept evolving (think "strict", but "stricter", "stricter still", ...) to a simpler and easier to compile/JIT language.
  - ayaros 1y ago
    Yes, this is what I want too. Give me "stricter" mode.
  - fngjdflmdflg 1y ago
    I want JS with sound types. It's interesting how sound types can't be added to JS because runtime checks would be too expensive, but then so much of what makes JS slow is having to check types all the time anyway, and the only way to speed it up is to retroactively infer the types. I want types plus a "use typechecked" that tells the VM I already did some agreed upon level of compile-time checks and now it only needs to do true runtime checks that can't be done at compile time.
    - teaearlgraycold 1y ago
      The most likely path forward on that would be a Typescript AOT compiler, maybe with some limitations on the code you write.
      - fngjdflmdflg 1y ago
        Compiled to what, wasm?
        teaearlgraycold 1y ago
ot 1y ago
The SWAR escaping algorithm [1] is very similar to the one I implemented in Folly JSON a few years ago [2]. The latter works on 8 byte words instead of 4 bytes, and it also returns the position of the first byte that needs escaping, so that the fast path does not add noticeable overhead on escape-heavy strings. [1] https://source.chromium.org/chromium/_/chromium/v8/v8/+/5cbc55a855df103fa257fb0db1cc72db72706488:src/json/json-stringifier.cc;dlc=c0b1106da565c4baecb23dc06272caefc50b6760 https://source.chromium.org/chromium/_/chromium/v8/v8/+/5cbc... [2] https://github.com/facebook/folly/commit/2f0cabfb48b8a8df84f6453ef055e03ee1a34d51 https://github.com/facebook/folly/commit/2f0cabfb48b8a8df84f...
- hairtuq 1y ago
  If you want to optimize it a little more, you can combine isLess(s, 0x20) and isChar('"') into isLess(s ^ (kOnes * 0x02), 0x21) (this works since '"' is 0x22).
pyrolistical 1y ago
> Optimizing the underlying temporary buffer So array list instead of array?
greatgib 1y ago
An important question that was not addressed is whether the general path will be slower to account for what is needed to check first if the fast path can be used.
- Leszek 1y ago
  It's not - the general path is a bailout for the fast path which continues where the fast path stopped, so you don't have to check the whole object for fastness (and you get the fast path up until the bailout)
lifthrasiir 1y ago
As usual, the advancement in double-to-string algorithms is usually driven by JSON (this time Dragonbox).
t1234s 1y ago
speed is always good!
stephenlf 1y ago
Yo nice
Tiberium 1y ago
V8 is extremely good, but (maybe due to JS itself?) it still falls short of LuaJIT and even JVM performance. Although at least for JVM it takes way longer to warm up than the other two.
- MrBuddyCasino 1y ago
  „even“ Hombre, you’re about the best there is.
  - xxs 1y ago
    that 'even' made me chuckle - exactly the same 'reaction'
- Cthulhu_ 1y ago
  > maybe due to JS itself? Nail on the head; a lot of JS overhead is due to its dynamic nature. asm.js disallowed some of this dynamic behaviour (like changing the shape of objects, iirc), meaning they could skip a lot of these checks.
- mhh__ 1y ago
  It's JS, V8 is afaict much more advanced than luajit and jvm. Although java also has the advantage of not having to be ~ real time (i.e. has a compiler)
jongjong 1y ago
JSON serialization is already quite fast IMO so this is quite good. I think last time I compared JSON serialization to Protocol Buffers, JSON was just a little bit slower for typical scenarios but not materially so. These kinds of optimizations can shift the balance in terms of performance. JSON is a great minimalist format which is both human and machine readable. I never quite understood the popularity of ProtoBuf; the binary format is a major sacrifice to readability. I get that some people appreciate the type validation but it adds a lot of complexity and friction to the transport protocol layer.
- hamandcheese 1y ago
  For me the appeal of protobuf is the wire-format forward-backward compatibility. It's hard enough to not break logical compatibility, so I appreciate not having to think too hard about wire compat. You can of course solve the same thing with JSON, but, well, YOU have to solve it. (Also worth noting, there are a lot of things I don't like about the grpc ecosystem so I don't actually use it that much. But this is one of the pieces I really like a lot).
  - nasretdinov 1y ago
    Arguably JSON doesn't have this problem at all since it encodes the field names too. The only thing it doesn't handle is field renames, but I mean, come on, you know you can't rename a field in public API anyways :)
    - jongjong 1y ago
      I appreciate this comment. It does seem like some technologies get credit for solving problems that they created.
      - hamandcheese 1y ago
        Implement your own RPC system with JSON in a statically typed language and you will see what I mean.
tisdadd 1y ago
I will need to check this vs the usual safe-stable-stringify package I usually use in my projects now when I'm back on the computer, but it is always nice to see the speedup.
65 1y ago
I'd like to see how object duplication now compares in speed when using JSON.parse(JSON.stringify()) vs. recursive duplication.
- Cthulhu_ 1y ago
  Also take `structuredClone()` in this comparison; I don't understand why parse/stringify is still a thing, it's a workaround. I'm sure there can be a special code path to make this particular use case super fast or infer that it needs to create a full copy of an object, but there shouldn't be one.
bgdkbtv 1y ago
Unrelated, but v8.dev website is incredibly fast! Thought it would be content preloading with link hovering but no. Refreshing
- Culonavirus 1y ago
  Speaking of websites, does anyone know when will this land in Node? Node 24 has v8 13.6, and this is 13.8... I mean, this seems like a too big of a performance upgrade to just put it in the next release, especially since Node 24 will be the next LTS version.
  - Snafuh 1y ago
    There is a PR open since June. It's currently blocked by a MacOS CI issue. https://github.com/nodejs/node/pull/58491 https://github.com/nodejs/node/pull/58491
- hereonout2 1y ago
  It's also very simple and free of ads or any other extraneous clutter, a bit like hacker news, which is also fast. There's probably a lesson in there somewhere.
- qw 1y ago
  Looking at the site it seems to be a (static?) HTML and shared "main.css" and "main.js" files. Both files can be cached by the browser, so it only needs to download a few KB of compressed HTML for each page. I don't think we would notice much of a difference in the navigation from one page to another if they used content preloading It's how we used to make websites before SPA, and it's refreshing to see that it still makes a noticeable difference even on today's powerful CPUs and high speed networks.
dvrp 1y ago
Woah, I didn't know about Packed SIMD/SIMD within a register (SWAR).
notpushkin 1y ago
> No indexed properties on objects: The fast path is optimized for objects with regular, string-based keys. If an object contains array-like indexed properties (e.g., '0', '1', ...), it will be handled by the slower, more general serializer. Any idea why?
- Timwi 1y ago
  I wonder that too. Are they saying that objects with integer-looking keys are serialized as JSON arrays?? Surely not...?
- inbx0 1y ago
  My guess would be because they affect property ordering, complicating the stringification. The default object property iteration rules in JS define that numeric properties are traversed first in their numeric order, and only then others in the order they were added to the object. Since the numbers need to be in their numeric, not lexical, order, the engine would also need to parse them to ints before sorting. > JSON.stringify({b: null, 10: null, 1: null, a: null}) '{"1":null,"10":null,"b":null,"a":null}'
seanwilson 1y ago
Slightly related: I die a little inside each time I see `JSON.parse(JSON.stringify(object))` thinking about the inefficiencies involved compared to how you'd do this in a more efficient language. There's structuredClone (https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone https://developer.mozilla.org/en-US/docs/Web/API/Window/stru... https://caniuse.com/?search=structuredClone https://caniuse.com/?search=structuredClone) with baseline support (93% of users), but it doesn't work if fields contain DOM objects or functions meaning you might have to iterate over and preprocess objects before cloning so more error-prone, manual and again inefficient?
- remify 1y ago
  March 2022 is not that long ago for a codebase. It takes time but Javascript has come a long way and it's definitely going in the right direction.
  - mary-ext 1y ago
    also depends on the codebase, if you use frameworks with deep reactivity like Vue, you can't do structuredClone without toRaw (which only works if the object is shallow) as it'd throw on proxy objects. Svelte has `$state.snapshot()` for this reason I believe.
smagin 1y ago
Unrelated but I have the easiest design improvement for your website: change <html> background color to #4285f4 (same as in topbar) so it looks like a sheet of paper on a blue base
- ykrishnan 1y ago
  Yes...It does look better.
bob1029 1y ago
How is this compared to other ecosystems? I've been serializing JSON for about a decade and it's been so fast I haven't really thought about it. Simdjson can do gigabytes per second per core. Once you factor in prefetching, branch prediction, etc., a highly optimized JSON serializer should be effectively free for most real world workloads. The part where json sucks is IO overhead when modifying blobs. It doesn't matter how fast your serializer is if you have to push 100 megabytes to block storage every time a user changes a boolean preference.
- enedil 1y ago
  I think the main issue is that JSON is capable of serializing JavaScript Objects, which are often much more complex than a simple hashmap.
deathwarmedover 1y ago
Not that I doubt the value of the work, and the reasoning of its performance directly affecting common operations makes intuitive sense, but I would have liked to hear more about what concrete problems were being solved. Was there any interesting data across the V8 ecosystem about `JSON.stringify` dominating runtimes?
- abdulhaq 1y ago
  it doesn't need to dominate run times when it's being called by hundreds of millions of pages every day. The power saving worldwide will be considerable.
gampleman 1y ago
> No replacer or space arguments: Providing a replacer function or a space/gap argument for pretty-printing are features handled exclusively by the general-purpose path. The fast path is designed for compact, non-transformed serialization. Do we get this even if you call `JSON.stringify(data, null, 0)`? Or do the arguments literally have to be undefined?
- tln 1y ago
  I don't think so. I just got ~2.4 for a 512KB json using JSON.stringify(data, null, 0) and ~1.4 for JSON.stringify(data). JSON.stringify(data, undefined, undefined) was the same as JSON.stringify(data). Other combos were slower https://microsoftedge.github.io/Demos/json-dummy-data/512KB.json https://microsoftedge.github.io/Demos/json-dummy-data/512KB.... Chrome 138.0.7204.184
countofarthur 1y ago
Reminded me the quote "do things quickly"
harel 1y ago
Am I the only one that finds the use of "stringify" as the method name to serialise a data structure a bit... unsavoury on the tongue? A touch Mickey Mouse? I always wondered why this word was chosen for something so "core".
- sphars 1y ago
  According to the guy who created JavaScript, Brendan Eich[0]: > On Nov 16, 2008, at 11:57 PM, Peter Michaux wrote: > > The name "JSON.stringify" seems a little too "Web 2.0" cool to me. > Hardly. It's hacker dictionary material, old sk00l. > > Is there any reason a more usual and serious sounding option like "serialize" was not used? > Ugh, Web 1.0 my-first-Java-serializable-implementation anti-nostalgia vapors. [0]: https://web.archive.org/web/20100718152229/https://mail.mozilla.org/pipermail/es-discuss/2008-November/008121.html https://web.archive.org/web/20100718152229/https://mail.mozi...
  - harel 1y ago
    That's exactly it though - That's the word: A bit too web 2.0.... Serialize, Marshal, toString: timeless. Stringify: Trendy, gone with the winds...
  - falconertc 1y ago
    When the next best option is "serialize", suddenly stringify doesn't seem so bad. I would prefer a silly-sounding but immediately clear function to a more abstract concept.
Hendrikto 1y ago
Absolutely incredible how much effort has been put into making a horrible language bearable and performant. Imagine how far we could have come if we started from a reasonable basis.

458 points by emschwartz 1y ago

JSON encoding is a huge impediment to interprocess communication in NodeJS. Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main thread. I’ve seen people stringify arrays one entry at a time. Sounds like maybe they are doing that internally now. If anything I would encourage the V8 team to go farther with this. Can you avoid bailing out for subsets of data? What about the CString issue? Does this bring faststr back from the dead?

jcdavis 1y ago
Based off of my first ever forays into node performance analysis last year, JSON.stringify was one of the biggest impediments to just about everything around performant node services. The fact that everyone uses stringify to for dict keys, the fact that apollo/express just serializes the entire response into a string instead of incrementally streaming it back (I think there are some possible workarounds for this, but they seemed very hacky) As someone who has come from a JVM/go background, I was kinda shocked how amateur hour it felt tbh.
- MehdiHK 1y ago
  > JSON.stringify was one of the biggest impediments to just about everything around performant node services That's what I experienced too. But I think the deeper problem is Node's cooperative multitasking model. A preemptive multitasking (like Go) wouldn't block the whole event-loop (other concurrent tasks) during serializing a large response (often the case with GraphQL, but possible with any other API too). Yeah, it does kinda feel like amateur hour.
  - Rohansi 1y ago
    That's not really a Node problem but a JavaScript problem. Nothing about it was built to support parallel execution like Go and other languages. That's why they use web workers, separate processes, etc. to make use of more than a single core. But then you'll probably be dependent on JSON serialization to send data between those event loops.
    - miroljub 1y ago
      > That's not really a Node problem but a JavaScript problem. Nowadays Node is JavaScript. They are the guys driving JavaScript standards and new features for a decade or so. Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ...
      - promiseofbeans 1y ago
        I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server. Yes, there have been a lot of advances in modern JS for things like atomics and other fun memory stuff, but that's just the natrual progression for a language as popular as JS. The 3 main JS engines are still developed primarily for web browsers, and web developers are the primary audience considered in ES language discussions (although I'll concede that in recent years server runtimes have been considered more and more)
        coldtea 1y ago
        >I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server. Clients are 90% still v8, so hardly different than Node.
      - jerf 1y ago
        "Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ..." In principle perhaps not. In practice it is abundantly clear now from repeated experience that trying to retrofit such things on to a scripting language that has been single-threaded for decades is an extremely difficult and error-prone process that can easily take a decade to reach production quality, if indeed it ever does, and then take another decade or more to become something you can just expect to work, expect to find libraries that use properly, etc. I don't think it's intrinsic to scripting languages. I think someone could greenfield one and have no more problems with multithreading than any other language. It's trying to put it into something that has been single-threaded for a decade or two already that is very, very hard. And to be honest, given what we've seen from the other languages that have done this, I'd have a very, very, very serious discussion with the dev team as to whether it's actually worth it. Other scripting languages have put a lot of work into this and it is not my perception that the result has been worth the effort.
  - gwbas1c 1y ago
    > Yeah, it does kinda feel like amateur hour. NodeJS is intended for IO-heavy workloads. Specifically, it's intended for workloads that don't benefit from parallel processing in the CPU. This is because Javascript is strictly a single-threaded language; IE, it doesn't support shared access to memory from multiple threads. (And this is because Javascript was written for controlling a UI, and historically UI is all handled on a single thread.) If you need true multithreading, there are plenty of languages that support it. Either you picked the wrong language, or you might want to consider creating a library in another language and calling into it from NodeJS.
    - MehdiHK 1y ago
      > If you need true multithreading I didn't say multithreading anywhere. Mutitasking (concurrency) != Multithreading. You can do pre-emptive concurrency with a single thread in other runtimes, where each task gets a pre-defined amount of CPU time slice, that solves fair scheduling for both IO and CPU-bound workloads. Nobody is supposed to pick NodeJS for CPU-bound workload, but you cannot escape JSON parse/stringify event-loop blocking in practice (which is CPU-bound).
- hinkley 1y ago
  > Based off of my first ever forays into node performance analysis last year, JSON.stringify was one of the biggest impediments to just about everything around performant node services Just so. It is, or at least can be, the plurality of the sequential part of any Amdahl's Law calculation for Nodejs. I'm curious if any of the 'side effect free' commentary in this post is about moving parts of the JSON calculation off of the event loop. That would certainly be very interesting if true. However for concurrency reasons I suspect it could never be fully off. The best you could likely do is have multiple threads converting the object while the event loop remains blocked. Not entirely unlike concurrent marking in the JVM.
- dmit 1y ago
  Node is the biggest impediment to performant Node services. The entire value proposition is "What if you could hire people who write code in the most popular programming language in the world?" Well, guess what
  - hinkley 1y ago
    Nodejs will never be as bad as VB was.
    - jk3000 1y ago
      More or less accidentally I turned a simple Excel spreadsheet into a sizable data management system. Once you learn where the bottlenecks are, it is surprising how fast VB is nowadays.
    - schrodinger 1y ago
      Low bar!
    - germandiago 1y ago
      I know Javascript is fast but... I cannot go with such a messy ecosystem. I find Python highly preferrable for my backend code for more or less low and middle traffic stuff. I know Python is not that good deployment-wise, but the language is really understandable, I have tools for every use case, I can easily provide bindings from C++ code and it is a joy to work with. If on top of that, they keep increasing its performance, I think I will stick to it for lots of backend tasks (except for high performance, where I have lately been doing with C++ and Capnproto RPC for distributed stuff).
      - m-schuetz 1y ago
        It comes down to language preferences. I find Python to be the worst thing computer science has to offer. No nested scoping in functions, variables leak through branches and loops due to lack of scopes, no classic for loops, but worst of all, installing python packages and frameworks never ever goes smoothly. I would like to love Jupyter notebooks because Notebooks are great for prototyping, but Jupyter and Python plotting libs are so clunky and slow, I always have to fall back to Node or writing a web page with JS and svg for plotting and prototyping.
- deleted 1y ago
  [deleted]
brundolf 1y ago
Yeah. I think I've only ever found one situation where offloading work to a worker saved more time than was lost through serializing/deserializing. Doing heavy work often means working with a huge set of data- which means the cost of passing that data via messages scales with the benefits of parallelizing the work.
- hinkley 1y ago
  I think the clues are all there in the MDN docs for web workers. Having a worker act as a forward proxy for services; you send it a URL, it decides if it needs to make a network request, it cooks down the response for you and sends you the condensed result. Most tasks take more memory in the middle that at the beginning and end. And if you're sharing memory between processes that can only communicate by setting bytes, then the memory at the beginning and end represents the communication overhead. The latency. But this is also why things like p-limit work - they pause an array of arbitrary tasks during the induction phase, before the data expands into a complex state that has to be retained in memory concurrent with all of its peers. By partially linearizing you put a clamp on peak memory usage that Promise.all(arr.map(...)) does not, not just the thundering herd fix.
dwattttt 1y ago
Now to just write the processing code in something that compiles to WebAssembly, and you can start copying and sending ArrayBuffers to your workers! Or I guess you can do it without the WebAssembly step.
- hinkley 1y ago
  A JSON.toBuffer would be another good addition to V8. There are a couple code paths that look like they might do this, but from all accounts it goes Object->String->Buffer, and for speed you want to skip the intermediate.
  - dwattttt 1y ago
    I was actually imagining skipping the Object step; if you go from wire -> buffer, and only ever work on it in buffer form (i.e. in WebAssembly, in a language more amenable to working on buffers/bytes), you skip needing the Object -> JSON step. Notwithstanding whatever you need to do in the wire -> buffer step.
    - hinkley 1y ago
      Working with bytes in JS is still gross and I wouldn’t wish it on my worst enemy. Like I said, if you had a way to automate it, it wouldn’t be so bad.
nijave 1y ago
Same problem in Python. It'd be nice to have good/efficient IPC primitives with higher level APIs on top for common patterns
userbinator 1y ago
You mean: > JSON encoding is a huge impediment to communication I wonder how much computational overhead JSON'ing adds to communications at a global scale, in contrast to just sending the bytes directly in a fixed format or something far more efficient to parse like ASN.1.
- hinkley 1y ago
  No. Because painful code never gets optimized as much as less painful code. People convince themselves to look elsewhere, and an incomplete picture leads to local optima.
  - hinkley 1y ago
    BTW, I often shorthand this as, "I'm not so much better [at optimization] as I am more stubborn." The number of times I've gone in looking for 10%, backed out a bit and rearranged the code first to find 25%, better maintainability, and space for a feature that marketing has been bitching about for three years and development keeps insisting we cannot do in any reasonable amount of time? Probably averages out to at least three times per employer, which is a good number of miracles to perform.
tgv 1y ago
> If anything I would encourage the V8 team to go farther with this. That feels the wrong way to go. I would encourage the people that have this problem to look elsewhere. Node/V8 isn't well suited to backend or the heavier computational problems. Javascript is shaped by web usage, and it will stay like that for some time. You can't expect the V8 team to bail them out. The Typescript team switched to Go, because it's similar enough to TS/JS to do part of the translation automatically. I'm no AI enthousiast, but they are quite good at doing idiomatic translations too.
- com2kid 1y ago
  > Node/V8 isn't well suited to backend Node was literally designed to be good for one thing - backend web service development. It is exceptionally good at it. The runtime overhead is tiny compared to the JVM, the async model is simple as hell to wrap your head around and has a fraction of the complexity of what other languages are doing in this space, and Node running on a potato of a CPU can handle thousands of requests per second w/o breaking a sweat using the most naively written code. Also the compactness of the language is incredible, you can get a full ExpressJS service up and running, including auth, in less than a dozen lines of code. The amount of magic that happens is almost zero, especially compared to other languages and frameworks. I know some people like their magic BS (and some of the stuff FastAPI does is nifty), but Express is "what you see is what you get" by default. > The Typescript team switched to Go, because it's similar enough to TS/JS to do part of the translation automatically. The TS team switched to go because JS is horrible at anything that isn't strings or doubles. The lack of an int type hinders the language, so runtimes do a lot of work to try and determine when a number can be treated like an int. JS's type system is both absurdly flexible and also limiting. Because JS basically allows you to do anything with types, Typescript ends up being one of the most powerful type systems that has seen mass adoption. (Yes other languages have more powerful type systems, but none of them have the wide spread adoption TS does). If I need to model a problem domain, TS is an excellent tool for doing so. If I need to respond to thousands of small requests, Node is an excellent tool for doing so. If I need to do some actual computation on those incoming requests, eh, maybe pick another tech stack. But for the majority of service endpoints that consist of "get message from user, query DB, reformat DB response, send to user"? Node is incredible at solving that problem.
deadbabe 1y ago
When it comes time to do serious work in Node, that's when you start using TypedArrays and SharedArrayBuffers and work with straight binary data. stringifying is mostly for toy apps and smaller projects.
- hinkley 1y ago
  If I took all the coworkers I’ve had in 30 years of coding whom I could really trust with the sort of bit fiddling array buffers, I could populate maybe two companies and everyone else would be fucked. TypedArray is a toy. Very few domains actually work well with this sort of data. Statistics, yes. Games? Do all the time, but also games: are full of glitches used by speed runners, due to games playing fast and loose to maintain an illusion they are doing much more per second than they should be able to. DataView is a bit better. I am endlessly amazed at how many times I managed to read people talk about TypedArrays and SharedByteArrays before I discovered that DataView exists and has existed basically forever. Somebody should have mentioned it a lot, lot sooner.
  - deadbabe 1y ago
    DataView has a lot of overhead. Just do it raw.
zamalek 1y ago
> Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main thread. Why not use structuredClone to communicate with the worker? So long as your object upholds all the rules you can pass it into postMessage directly.
- hinkley 1y ago
  Structured clone only gets you a new object in this heap, not a new object in an isolate. You’re still doing stringify/parse under the hood every time you sendMessage.
  - zamalek 1y ago
    postMessage uses it transparently: https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
    - hinkley 1y ago
      So I wonder if any of these improvements could be applied to structuredClone. Benchmarks aren’t showing structuredClone favorably versus JSON round tripping. Likely because JSON-compatible data structures are less complex than clonable data. I suspect with this change JSON will now be faster than structuredClone.
      - zamalek 1y ago
        > Benchmarks aren’t showing structuredClone favorably versus JSON round tripping. Which ones? Structured clone seems to be approximately the same as FF according to this (structuredClone is slightly faster on my machine, probably margin of error): https://measurethat.net/Benchmarks/Show/23052/0/structuredclone-vs-jsonparse-jsonstringify https://measurethat.net/Benchmarks/Show/23052/0/structuredcl... (Linux: FF 141, Chromium 138).
cogman10 1y ago
It's a major problem for JVM performance as well. Json encoding is simply fundamentally an expensive thing to do. One thing that improves performance for the JVM that'd be nice to see in node realm is that JSON serialization libraries can stream out the serialization. One of the major costs of JSON is the memory footprint. Strings take up a LOT more space in memory than a regular object does. Since the JVM typically only uses JSON as a communication protocol, streaming it out makes a lot of sense. The IO (usually) takes long enough to give a CPU reprieve while simultaneously saving memory.

MutedEstate45 1y ago

I really like seeing the segmented buffer approach. It's basically the rope data structure trick I used to hand-roll in userland with libraries like fast-json-stringify, now native and way cleaner. Have you run into the bailout conditions much? Any replacer, space, or custom .toJSON() kicks you back to the slow path?

jonas21 1y ago

The part that was most surprising to me was how much the performance of serializing floating-point numbers has improved, even just in the past decade [1]. [1] https://github.com/jk-jeon/dragonbox?tab=readme-ov-file#performance https://github.com/jk-jeon/dragonbox?tab=readme-ov-file#perf...

jameshart 1y ago
Roundtripping IEEE floating point values via conversion to decimal UTF-8 strings and back is a ridiculously fragile process, too, not just slow. The difference between which values are precisely representable in binary and which are precisely representable in decimal means small errors can creep in.
- gugagore 1y ago
  You don't have to precisely represent the float in decimal. You just have to have each float have a unique decimal representation, which you can guarantee if you include enough digits: 9 for 32-bit floats, and 17 for 64-bit floats. https://randomascii.wordpress.com/2012/02/11/they-sure-look-equal/ https://randomascii.wordpress.com/2012/02/11/they-sure-look-...
  - jameshart 1y ago
    And you need to trust that whoever is generating the JSON you’re consuming, or will consume the JSON you generate, is using a library which agrees about what those representations round to.
    - jk-jeon 1y ago
      Note that the consumer side doesn't really have a lot of ambiguity. You just read the number, compute its precise value as written, round it to the closest binary representation with banker's rounding. You do anything other than this only under very special circumstances. Virtually all ambiguity lies on the producer side, which can be cleared out by using any of the formatting algorithms with the roundtripping-guarantee. EDIT: If you're talking about decimal->binary->decimal round-tripping, it's a completely different story though.

iouser 1y ago

Did you run any tests/regressions against the security problems that are common with parsers? Seems like the solution might be at risk of creating CVEs later

rpearl 1y ago
...Do you think that v8 doesn't have tests for what might be one of the most executed userspace codepaths in the world?

taeric 1y ago

I confess that I'm at a bit of a loss to know what sort of side effects would be common when serializing something? Is there an obvious class of reasons for this that I'm just accidentally ignoring right off?

vinkelhake 1y ago
A simple example is `toJSON`. If an object defines that method, it'll get invoked automatically by JSON.stringify and it could have arbitrary side effects. I think it's less about side effects being common when serializing, just that their fast path avoids anything that could have side effects (like toJSON). The article touches briefly on this.
- taeric 1y ago
  Right, I get that you could define something to have side effects. My question is why would you? What are some expected visible side effects of converting something to json? That said, I see that they called it out as you say, now. When I first read it, I thought they watched for side effects. I'm assuming they have an allow list on all standard types. The date types, in particular, often have a toJson that seems like it should still be used? (Or am I wrong on that, too? :D )
kevingadd 1y ago
Calling a property getter can have side effects, so if you serialize an object with a getter you have to be very cautious to make sure nothing weird happens underneath you during serialization. People have exploited this sort of side effect to get bug bounties before via type confusion attacks, iirc.
- taeric 1y ago
  Right, I get how you could make something that would cause issues. I'm curious why you would want to? :D
  - kevingadd 1y ago

monster_truck 1y ago

I don't think v8 gets enough praise. It is fucking insane how fast javascript can be these days

andyferris 1y ago
Yeah, it is quite impressive! It's a real example of "you can solve just about anything with a billion dollars" though :) I'd prefer JavaScript kept evolving (think "strict", but "stricter", "stricter still", ...) to a simpler and easier to compile/JIT language.
- ayaros 1y ago
  Yes, this is what I want too. Give me "stricter" mode.
- fngjdflmdflg 1y ago
  I want JS with sound types. It's interesting how sound types can't be added to JS because runtime checks would be too expensive, but then so much of what makes JS slow is having to check types all the time anyway, and the only way to speed it up is to retroactively infer the types. I want types plus a "use typechecked" that tells the VM I already did some agreed upon level of compile-time checks and now it only needs to do true runtime checks that can't be done at compile time.
  - teaearlgraycold 1y ago
    The most likely path forward on that would be a Typescript AOT compiler, maybe with some limitations on the code you write.
    - fngjdflmdflg 1y ago
      Compiled to what, wasm?
      - teaearlgraycold 1y ago

ot 1y ago

The SWAR escaping algorithm [1] is very similar to the one I implemented in Folly JSON a few years ago [2]. The latter works on 8 byte words instead of 4 bytes, and it also returns the position of the first byte that needs escaping, so that the fast path does not add noticeable overhead on escape-heavy strings. [1] https://source.chromium.org/chromium/_/chromium/v8/v8/+/5cbc55a855df103fa257fb0db1cc72db72706488:src/json/json-stringifier.cc;dlc=c0b1106da565c4baecb23dc06272caefc50b6760 https://source.chromium.org/chromium/_/chromium/v8/v8/+/5cbc... [2] https://github.com/facebook/folly/commit/2f0cabfb48b8a8df84f6453ef055e03ee1a34d51 https://github.com/facebook/folly/commit/2f0cabfb48b8a8df84f...

hairtuq 1y ago
If you want to optimize it a little more, you can combine isLess(s, 0x20) and isChar('"') into isLess(s ^ (kOnes * 0x02), 0x21) (this works since '"' is 0x22).

pyrolistical 1y ago

> Optimizing the underlying temporary buffer So array list instead of array?

greatgib 1y ago

An important question that was not addressed is whether the general path will be slower to account for what is needed to check first if the fast path can be used.

Leszek 1y ago
It's not - the general path is a bailout for the fast path which continues where the fast path stopped, so you don't have to check the whole object for fastness (and you get the fast path up until the bailout)

lifthrasiir 1y ago

As usual, the advancement in double-to-string algorithms is usually driven by JSON (this time Dragonbox).

t1234s 1y ago

speed is always good!

stephenlf 1y ago

Yo nice

Tiberium 1y ago

V8 is extremely good, but (maybe due to JS itself?) it still falls short of LuaJIT and even JVM performance. Although at least for JVM it takes way longer to warm up than the other two.

MrBuddyCasino 1y ago
„even“ Hombre, you’re about the best there is.
- xxs 1y ago
  that 'even' made me chuckle - exactly the same 'reaction'
Cthulhu_ 1y ago
> maybe due to JS itself? Nail on the head; a lot of JS overhead is due to its dynamic nature. asm.js disallowed some of this dynamic behaviour (like changing the shape of objects, iirc), meaning they could skip a lot of these checks.
mhh__ 1y ago
It's JS, V8 is afaict much more advanced than luajit and jvm. Although java also has the advantage of not having to be ~ real time (i.e. has a compiler)

jongjong 1y ago

JSON serialization is already quite fast IMO so this is quite good. I think last time I compared JSON serialization to Protocol Buffers, JSON was just a little bit slower for typical scenarios but not materially so. These kinds of optimizations can shift the balance in terms of performance. JSON is a great minimalist format which is both human and machine readable. I never quite understood the popularity of ProtoBuf; the binary format is a major sacrifice to readability. I get that some people appreciate the type validation but it adds a lot of complexity and friction to the transport protocol layer.

hamandcheese 1y ago
For me the appeal of protobuf is the wire-format forward-backward compatibility. It's hard enough to not break logical compatibility, so I appreciate not having to think too hard about wire compat. You can of course solve the same thing with JSON, but, well, YOU have to solve it. (Also worth noting, there are a lot of things I don't like about the grpc ecosystem so I don't actually use it that much. But this is one of the pieces I really like a lot).
- nasretdinov 1y ago
  Arguably JSON doesn't have this problem at all since it encodes the field names too. The only thing it doesn't handle is field renames, but I mean, come on, you know you can't rename a field in public API anyways :)
  - jongjong 1y ago
    I appreciate this comment. It does seem like some technologies get credit for solving problems that they created.
    - hamandcheese 1y ago
      Implement your own RPC system with JSON in a statically typed language and you will see what I mean.

tisdadd 1y ago

I will need to check this vs the usual safe-stable-stringify package I usually use in my projects now when I'm back on the computer, but it is always nice to see the speedup.

65 1y ago

I'd like to see how object duplication now compares in speed when using JSON.parse(JSON.stringify()) vs. recursive duplication.

Cthulhu_ 1y ago
Also take `structuredClone()` in this comparison; I don't understand why parse/stringify is still a thing, it's a workaround. I'm sure there can be a special code path to make this particular use case super fast or infer that it needs to create a full copy of an object, but there shouldn't be one.

bgdkbtv 1y ago

Unrelated, but v8.dev website is incredibly fast! Thought it would be content preloading with link hovering but no. Refreshing

Culonavirus 1y ago
Speaking of websites, does anyone know when will this land in Node? Node 24 has v8 13.6, and this is 13.8... I mean, this seems like a too big of a performance upgrade to just put it in the next release, especially since Node 24 will be the next LTS version.
- Snafuh 1y ago
  There is a PR open since June. It's currently blocked by a MacOS CI issue. https://github.com/nodejs/node/pull/58491 https://github.com/nodejs/node/pull/58491
hereonout2 1y ago
It's also very simple and free of ads or any other extraneous clutter, a bit like hacker news, which is also fast. There's probably a lesson in there somewhere.
qw 1y ago
Looking at the site it seems to be a (static?) HTML and shared "main.css" and "main.js" files. Both files can be cached by the browser, so it only needs to download a few KB of compressed HTML for each page. I don't think we would notice much of a difference in the navigation from one page to another if they used content preloading It's how we used to make websites before SPA, and it's refreshing to see that it still makes a noticeable difference even on today's powerful CPUs and high speed networks.

dvrp 1y ago

Woah, I didn't know about Packed SIMD/SIMD within a register (SWAR).

notpushkin 1y ago

> No indexed properties on objects: The fast path is optimized for objects with regular, string-based keys. If an object contains array-like indexed properties (e.g., '0', '1', ...), it will be handled by the slower, more general serializer. Any idea why?

Timwi 1y ago
I wonder that too. Are they saying that objects with integer-looking keys are serialized as JSON arrays?? Surely not...?
inbx0 1y ago
My guess would be because they affect property ordering, complicating the stringification. The default object property iteration rules in JS define that numeric properties are traversed first in their numeric order, and only then others in the order they were added to the object. Since the numbers need to be in their numeric, not lexical, order, the engine would also need to parse them to ints before sorting. > JSON.stringify({b: null, 10: null, 1: null, a: null}) '{"1":null,"10":null,"b":null,"a":null}'

seanwilson 1y ago

Slightly related: I die a little inside each time I see `JSON.parse(JSON.stringify(object))` thinking about the inefficiencies involved compared to how you'd do this in a more efficient language. There's structuredClone (https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone https://developer.mozilla.org/en-US/docs/Web/API/Window/stru... https://caniuse.com/?search=structuredClone https://caniuse.com/?search=structuredClone) with baseline support (93% of users), but it doesn't work if fields contain DOM objects or functions meaning you might have to iterate over and preprocess objects before cloning so more error-prone, manual and again inefficient?

remify 1y ago
March 2022 is not that long ago for a codebase. It takes time but Javascript has come a long way and it's definitely going in the right direction.
- mary-ext 1y ago
  also depends on the codebase, if you use frameworks with deep reactivity like Vue, you can't do structuredClone without toRaw (which only works if the object is shallow) as it'd throw on proxy objects. Svelte has `$state.snapshot()` for this reason I believe.

smagin 1y ago

Unrelated but I have the easiest design improvement for your website: change <html> background color to #4285f4 (same as in topbar) so it looks like a sheet of paper on a blue base

ykrishnan 1y ago
Yes...It does look better.

bob1029 1y ago

How is this compared to other ecosystems? I've been serializing JSON for about a decade and it's been so fast I haven't really thought about it. Simdjson can do gigabytes per second per core. Once you factor in prefetching, branch prediction, etc., a highly optimized JSON serializer should be effectively free for most real world workloads. The part where json sucks is IO overhead when modifying blobs. It doesn't matter how fast your serializer is if you have to push 100 megabytes to block storage every time a user changes a boolean preference.

enedil 1y ago
I think the main issue is that JSON is capable of serializing JavaScript Objects, which are often much more complex than a simple hashmap.

deathwarmedover 1y ago

Not that I doubt the value of the work, and the reasoning of its performance directly affecting common operations makes intuitive sense, but I would have liked to hear more about what concrete problems were being solved. Was there any interesting data across the V8 ecosystem about `JSON.stringify` dominating runtimes?

abdulhaq 1y ago
it doesn't need to dominate run times when it's being called by hundreds of millions of pages every day. The power saving worldwide will be considerable.

gampleman 1y ago

> No replacer or space arguments: Providing a replacer function or a space/gap argument for pretty-printing are features handled exclusively by the general-purpose path. The fast path is designed for compact, non-transformed serialization. Do we get this even if you call `JSON.stringify(data, null, 0)`? Or do the arguments literally have to be undefined?

tln 1y ago
I don't think so. I just got ~2.4 for a 512KB json using JSON.stringify(data, null, 0) and ~1.4 for JSON.stringify(data). JSON.stringify(data, undefined, undefined) was the same as JSON.stringify(data). Other combos were slower https://microsoftedge.github.io/Demos/json-dummy-data/512KB.json https://microsoftedge.github.io/Demos/json-dummy-data/512KB.... Chrome 138.0.7204.184

countofarthur 1y ago

Reminded me the quote "do things quickly"

harel 1y ago

Am I the only one that finds the use of "stringify" as the method name to serialise a data structure a bit... unsavoury on the tongue? A touch Mickey Mouse? I always wondered why this word was chosen for something so "core".

sphars 1y ago
According to the guy who created JavaScript, Brendan Eich[0]: > On Nov 16, 2008, at 11:57 PM, Peter Michaux wrote: > > The name "JSON.stringify" seems a little too "Web 2.0" cool to me. > Hardly. It's hacker dictionary material, old sk00l. > > Is there any reason a more usual and serious sounding option like "serialize" was not used? > Ugh, Web 1.0 my-first-Java-serializable-implementation anti-nostalgia vapors. [0]: https://web.archive.org/web/20100718152229/https://mail.mozilla.org/pipermail/es-discuss/2008-November/008121.html https://web.archive.org/web/20100718152229/https://mail.mozi...
- harel 1y ago
  That's exactly it though - That's the word: A bit too web 2.0.... Serialize, Marshal, toString: timeless. Stringify: Trendy, gone with the winds...
- falconertc 1y ago
  When the next best option is "serialize", suddenly stringify doesn't seem so bad. I would prefer a silly-sounding but immediately clear function to a more abstract concept.

Hendrikto 1y ago

Absolutely incredible how much effort has been put into making a horrible language bearable and performant. Imagine how far we could have come if we started from a reasonable basis.