what's faster async or sync ?

so I came across a video and it was talking about this article https://www.softwareatscale.dev/p/the-hidden-performance-cost-of-nodejs#:~:text=NodeJS%20and%20GraphQL%20are%20popular,promises%2C%20which%20degrades%20request%20performance. which says that the sync is a way faster approach than the promises/async and shows some tables showing the difference what would be the best approach since I always use async functions in serverless functions
The Hidden Performance Cost of NodeJS and GraphQL
NodeJS and GraphQL are popular technologies for building web applications, but in my experience, they come with certain scaling and performance tradeoffs to be aware of. tl;dr: GraphQL's modular structure generally leads to code that instantiates excessive promises, which degrades request performance. Benchmarks show a 2-3x latency increase.
9 Replies
Joao
Joao13mo ago
Faster !== better (not necessarily) The whole point of async is to fully take advantage of JavaScript's (since we're talking about JavaScript) event loop to continue to process further events while other long-running tasks continue to be worked on quietly in the background.
ABK | Muneer
ABK | Muneer13mo ago
But as backend like nodejs handling database and stuff wouldn't be more useful to be faster?
Joao
Joao13mo ago
Sure, if speed is the only concern. But in that case I'd argue there are better technologies you can reach for like Go or Rust. Let me put it this way: unless you are sure that you need to optimize for speed, there's really not reason to do it from the get go.
ABK | Muneer
ABK | Muneer13mo ago
This makes sense 👍
Joao
Joao13mo ago
If you are using synchronous processing and 10 requests come at the same time, one request will be processed faster while the other 9, sequentally, are waiting.
ABK | Muneer
ABK | Muneer13mo ago
Would node be best option for backend If the project is large or would it be better with other framework and languages like c#.net
Joao
Joao13mo ago
The gains shown in that benchmark are not that impressive to be honest. Plus, if in the sync request there's some other bottleneck in the database, network latency, etc., that will the entire Node.js process to stop working entirely. You are risking the entire server to stop to a halt to a lot of external conditions that may be out of your control. You should use what you or your team already knows. If you don't have any evidence that the server is the bottleneck when it comes to performance there's no reason to make the switch for something else for no reason.
ABK | Muneer
ABK | Muneer13mo ago
Great, i was just really thinking about it to know as programmer for the future and what would be best stuff to do / to learn
ErickO
ErickO13mo ago
bit of a silly article the problem isn't async per se, the solution was to make fewer graphql calls which...yeah ofc that is the solution, to a problem you created you can't avoid async code, if something needs to be async there is nothing you can do to avoid it, what you can do is limit how many times you query for something, it's like sending messages on discord and waiting for the other party to respond before saying anything else instead of just saying everything you have to say in one message how large or small a project is doesn't determine the language you use, instead you have to know what is it that you're looking to accomplish and what are the challenges node is really good for I/O stuff but if what you need isn't I/O speed but rather more CPU related like processing a lot of data then you wouldn't use node
Want results from more Discord servers?
Add your server