11 ms·

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 pe

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.
  - IX-103 1y ago
    I'm not a Node dev, but I've done some work with JavaScript on the web. Why are they using JSON to send data between v8 isolates when sendMessage allows sending whole objects (using an implementation defined binary serialization protocol under the hood that is 5-10x faster)?
    - Drakim 1y ago
      The biggest reason is most likely that they don't understand serialization, and simply think that objects are somehow being "sent" from one worker to another, which sounds like a cheap reference operation.
  - deleted 1y ago
    [deleted]
- 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.
  - 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]
deleted 1y ago
[deleted]

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.
- IX-103 1y ago
  I'm not a Node dev, but I've done some work with JavaScript on the web. Why are they using JSON to send data between v8 isolates when sendMessage allows sending whole objects (using an implementation defined binary serialization protocol under the hood that is 5-10x faster)?
  - Drakim 1y ago
    The biggest reason is most likely that they don't understand serialization, and simply think that objects are somehow being "sent" from one worker to another, which sounds like a cheap reference operation.
- deleted 1y ago
  [deleted]
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.
- 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]

deleted 1y ago

[deleted]