6 ms·

Code optimizations when using async/await

42 points by WolfOliver 5y ago

wa1987 5y ago
What's the pros/cons vs Promise.all([...])?
- WolfOliver 5y ago
  > Assuming the first request is done much faster than the second request, we can already utilize the CPU and doSomeCalculation while waiting for the second request to finish. In this case, the shown code is better than Promise.all([request1, request2]).
  - duped 5y ago
    Promise.all([request1.then(doSomeWork), request2]) ?
    - WolfOliver 5y ago
      yes this would work. It's just nested.
      - Footkerchief 5y ago
        The nesting has the advantage of directly expressing the dependency structure of the promises, which is otherwise a bit hard to infer.
bern4444 5y ago
This article doesn’t have any depth. TLDR: avoid blocking unrelated async requests via await. What’s far more interesting and harder to solve ergonomically is to parallelize async functions - parse responses to validate if they’ve succeeded or failed via Promise.allSettled, and then continue to work with the resolved values while retrying any failed requests. That’s what I was hoping this would go into but unfortunately it doesn’t.
- rileymat2 5y ago
  You would think this has no depth, but I have seen code like that waits in serial over and over. So clearly it is deep for the novice, which are in abundance.
- have_faith 5y ago
  Yeah this domain of problems doesn't seem to have a "neat" solution either built in or via some defacto library. I'm guessing you want to easily be able to say "attempt these requests, retry the failures at most these times, using this method of back-off, get back to me with the result" plus whatever other options of configurability for the failure modes. If you are using ReactJS then react-query does a very good job of handling these concerns for you specifically for syncing up with server side state locally.
- Footkerchief 5y ago
  The article makes a point that is both a) simple and self-evident and b) ignored by 90% of JS developers I've encountered, who are just trying to write procedural code and adding as many awaits as needed to achieve that. This is why I'm convinced that async should be opt-in, because most people don't use it effectively even when forced to acknowledge its existence.
- hinkley 5y ago
  I took one of these out recently and didn’t see much of an improvement. I was already fanning out a lot of requests so the sequential part was barely out of the noise floor. 5% at most. But I did have to add throttling to that request because of it. It had been previously limited by how fast the follow on request could be run. Doing more things in parallel doesn’t automatically make you faster. Every new batch of developers seems to have to learn this the hard way. Trying to do everything at once can make you more brittle. And does so, as often as not.
davidmurdoch 5y ago
I regularly write code in this optimized form and regularly get code review suggestions to change the code to make it sequential "for readability". Yes, it's harder to read, but it cuts runtime in half or more at the most performance critical part of the application. I think we developers too often try to cater to an imaginary lowest common denominator developer. Sometimes it is okay if code takes a little extra effort to read.
- happytoexplain 5y ago
  I agree - however, I don't think the developers we are imagining are imaginary. They exist and are common, but we shouldn't be catering to them as much as we sometimes do. Maybe that means leaning away from pragmatism and toward purism, but my hope is that software generally moves that way over time. Edit: Not "moves that way" as in becomes completely purist, just that I hope it lands a little closer to that side of the spectrum in the future.
  - hinkley 5y ago
    Coding for aesthetics is purism. Coding for human cognition/DevEx is pragmatism. They looks similar to an outsider, but the hills they choose for dying can be fairly different.
    - lowbloodsugar 5y ago
      Horses for courses. We have to admit that it takes a team with more skill to build a nuclear submarine than it does to inflate a dinghy, but conversely, no point paying nuclear engineers for your dinghy company. If you are building dinghies, or indeed mass producing dinghies for small clients, sure, pragmatism is not using complex async code. If you are building a nuclear submarine, the team better have a real good idea of how these parallel systems interact, don't deadlock the cooling system, and pragmatism might be "who knows TLA+?".
- darksaints 5y ago
  That can cut both ways. Sometimes optimizations reduce legibility even for advanced programmers, and often for very marginal improvements in performance...or no improvement in performance at all because they're not on the critical path. Sometimes it's okay to make code slower but more obvious as to what it is doing.
fathyb 5y ago
Awaiting a promise later on can lead to unhandled promise rejections, which will make Node.js crash in the future (currently prints a warning). Instead, Promise.all() and .then() should be used: let [result1, result2] = await Promise.all([ fetch('/request1').then(doSomeCalculation), fetch('/request2') ])
- WolfOliver 5y ago
  can you not use try catch blocks for this?
  - nosianu 5y ago
    Unless you stop executing code inside the try{} block by using "await" the try/catch is over when the error is thrown asynchronously later on. Leading to an asynchronous promise rejection. Yes your code is located inside a try/catch - but the execution has gone well past it unless you "await" the promise inside the try{}. That is a serious little trick question/problem for people not deeply familiar with async/await and promises in Javascript, so most newbie and middlish programmers. Either you only use stock-standard code constructs, so you refrain from creating promises and not immediately await-ing them, but passing them around*, or you really need to know and deeply understand promises and async/await. Relying on async/await but also additionally passing some un-await-ed promises around poses danger and needs a "senior" level understanding. The try/catch tricks people to think any promise created within is caught - but the try/catch exists only at one specific point in time. You have an additional dimension, your lexical code structure shows an incomplete picture. Whenever you create a promise, if you don't immediately await it, you must make sure that before there is another "await" you must attach a catch handler, or you may get an unhandled promise rejection at some point. Which usually nobody tests for, because on the happy path the program works just fine. Either attach one with .catch(), of if you use try/catch you must "await" the promise inside the try block - it must not resolve before code execution progresses past that block.
    - munchbunny 5y ago
      Wait, isn’t awaiting inside the try{} exactly how you’re supposed to handle it in the first place? Assuming you’re using await and not .catch(). And if you await without the try/catch you just end up with an unhandled exception at the await, no? I’ve yet to see any junior devs make the mistake of try-ing an unawaited promise. They’ve all seemed to appreciate the “async” aspect of the semantics up front.
saurik 5y ago
Note (for people who might try to mentally generalize this to other languages or situations) that this requires eager coroutines, which not all async/await frameworks support (and is often optional for the ones that do); for libraries that lean into "structured parallelism" you will need to pass these off to something that awaits them in some way (potentially as a group, or maybe to something that adapts the awaitable into an eager promise from a different system) for them to even start executing.
pizza 5y ago
Would love a programming language where optional pre- and post-invariants were a first-class language feature. So each line could be: <pre-invariants> | <line of code> | <post-invariants>. Then just let the compiler figure out the optimal ordering of things, figure out which things can be async automatically, and also perhaps this could be a built-in IDE static analysis tool to help catch logical errors earlier ¯\_(ツ)_/¯
- jerf 5y ago
  You can get something like that in Haskell. Functions are piles of statements that you can generally write in any order, and the compiler will deal with the resolution. You don't see this effect very strongly in Haskell though because you generally end up with small functions that don't have that many statements anyhow. (If one is sort of vaguely familiar with Haskell and thinking "what about do notation?" (or, less correctly but to the same point, "what about monads?") the answer is that do notation is a syntax sugar for introducing functions in a slightly different manner, using "<-" and some syntax transformations, so "do notation" is not a function but a function per <- symbol. Do notation affords tons of very small functions.) "figure out which things can be async automatically" If you want this, learn Go or Erlang (or Haskell). Personally I find having to manually label and deal with sync vs. "async" functions intolerable, but, fortunately, I don't have to. At the very least, though, I'd like a type system to help me out. This is something any type system can provide a lot of help with very easily, even sticking with manual async annotation. Getting a compile time error for sticking a promise for an int into an int would help keep a lot of this straight.
AtlasBarfed 5y ago
Wow, ten lines of pseudocode. Does anyone have any good site for ACTUAL state of the art in concurrency that discusses how go, rust, jvm, elixir, etc do things and the advantages? Node.JS is basically a single CPU using nonblocking I/O, great from the age of two to four core CPUs. But the future is dozens of CPUs working simultaneously to rapidly process the I/O that comes in from near-terabit networks and super SSDs using main memory bandwidth.
- AtlasBarfed 5y ago
  It looks like thread-per-core stuff like seastar (C++) and glommio (Rust) are still the state of the art, along with userland network drivers. glommio seems to be like a seda-thread-per-core using multiple rings as staged event buffers while running on dedicated cores.

42 points by WolfOliver 5y ago

wa1987 5y ago

What's the pros/cons vs Promise.all([...])?

WolfOliver 5y ago
> Assuming the first request is done much faster than the second request, we can already utilize the CPU and doSomeCalculation while waiting for the second request to finish. In this case, the shown code is better than Promise.all([request1, request2]).
- duped 5y ago
  Promise.all([request1.then(doSomeWork), request2]) ?
  - WolfOliver 5y ago
    yes this would work. It's just nested.
    - Footkerchief 5y ago
      The nesting has the advantage of directly expressing the dependency structure of the promises, which is otherwise a bit hard to infer.

bern4444 5y ago

This article doesn’t have any depth. TLDR: avoid blocking unrelated async requests via await. What’s far more interesting and harder to solve ergonomically is to parallelize async functions - parse responses to validate if they’ve succeeded or failed via Promise.allSettled, and then continue to work with the resolved values while retrying any failed requests. That’s what I was hoping this would go into but unfortunately it doesn’t.

rileymat2 5y ago
You would think this has no depth, but I have seen code like that waits in serial over and over. So clearly it is deep for the novice, which are in abundance.
have_faith 5y ago
Yeah this domain of problems doesn't seem to have a "neat" solution either built in or via some defacto library. I'm guessing you want to easily be able to say "attempt these requests, retry the failures at most these times, using this method of back-off, get back to me with the result" plus whatever other options of configurability for the failure modes. If you are using ReactJS then react-query does a very good job of handling these concerns for you specifically for syncing up with server side state locally.
Footkerchief 5y ago
The article makes a point that is both a) simple and self-evident and b) ignored by 90% of JS developers I've encountered, who are just trying to write procedural code and adding as many awaits as needed to achieve that. This is why I'm convinced that async should be opt-in, because most people don't use it effectively even when forced to acknowledge its existence.
hinkley 5y ago
I took one of these out recently and didn’t see much of an improvement. I was already fanning out a lot of requests so the sequential part was barely out of the noise floor. 5% at most. But I did have to add throttling to that request because of it. It had been previously limited by how fast the follow on request could be run. Doing more things in parallel doesn’t automatically make you faster. Every new batch of developers seems to have to learn this the hard way. Trying to do everything at once can make you more brittle. And does so, as often as not.

davidmurdoch 5y ago

I regularly write code in this optimized form and regularly get code review suggestions to change the code to make it sequential "for readability". Yes, it's harder to read, but it cuts runtime in half or more at the most performance critical part of the application. I think we developers too often try to cater to an imaginary lowest common denominator developer. Sometimes it is okay if code takes a little extra effort to read.

happytoexplain 5y ago
I agree - however, I don't think the developers we are imagining are imaginary. They exist and are common, but we shouldn't be catering to them as much as we sometimes do. Maybe that means leaning away from pragmatism and toward purism, but my hope is that software generally moves that way over time. Edit: Not "moves that way" as in becomes completely purist, just that I hope it lands a little closer to that side of the spectrum in the future.
- hinkley 5y ago
  Coding for aesthetics is purism. Coding for human cognition/DevEx is pragmatism. They looks similar to an outsider, but the hills they choose for dying can be fairly different.
  - lowbloodsugar 5y ago
    Horses for courses. We have to admit that it takes a team with more skill to build a nuclear submarine than it does to inflate a dinghy, but conversely, no point paying nuclear engineers for your dinghy company. If you are building dinghies, or indeed mass producing dinghies for small clients, sure, pragmatism is not using complex async code. If you are building a nuclear submarine, the team better have a real good idea of how these parallel systems interact, don't deadlock the cooling system, and pragmatism might be "who knows TLA+?".
darksaints 5y ago
That can cut both ways. Sometimes optimizations reduce legibility even for advanced programmers, and often for very marginal improvements in performance...or no improvement in performance at all because they're not on the critical path. Sometimes it's okay to make code slower but more obvious as to what it is doing.

fathyb 5y ago

Awaiting a promise later on can lead to unhandled promise rejections, which will make Node.js crash in the future (currently prints a warning). Instead, Promise.all() and .then() should be used: let [result1, result2] = await Promise.all([ fetch('/request1').then(doSomeCalculation), fetch('/request2') ])

WolfOliver 5y ago
can you not use try catch blocks for this?
- nosianu 5y ago
  Unless you stop executing code inside the try{} block by using "await" the try/catch is over when the error is thrown asynchronously later on. Leading to an asynchronous promise rejection. Yes your code is located inside a try/catch - but the execution has gone well past it unless you "await" the promise inside the try{}. That is a serious little trick question/problem for people not deeply familiar with async/await and promises in Javascript, so most newbie and middlish programmers. Either you only use stock-standard code constructs, so you refrain from creating promises and not immediately await-ing them, but passing them around*, or you really need to know and deeply understand promises and async/await. Relying on async/await but also additionally passing some un-await-ed promises around poses danger and needs a "senior" level understanding. The try/catch tricks people to think any promise created within is caught - but the try/catch exists only at one specific point in time. You have an additional dimension, your lexical code structure shows an incomplete picture. Whenever you create a promise, if you don't immediately await it, you must make sure that before there is another "await" you must attach a catch handler, or you may get an unhandled promise rejection at some point. Which usually nobody tests for, because on the happy path the program works just fine. Either attach one with .catch(), of if you use try/catch you must "await" the promise inside the try block - it must not resolve before code execution progresses past that block.
  - munchbunny 5y ago
    Wait, isn’t awaiting inside the try{} exactly how you’re supposed to handle it in the first place? Assuming you’re using await and not .catch(). And if you await without the try/catch you just end up with an unhandled exception at the await, no? I’ve yet to see any junior devs make the mistake of try-ing an unawaited promise. They’ve all seemed to appreciate the “async” aspect of the semantics up front.

saurik 5y ago

Note (for people who might try to mentally generalize this to other languages or situations) that this requires eager coroutines, which not all async/await frameworks support (and is often optional for the ones that do); for libraries that lean into "structured parallelism" you will need to pass these off to something that awaits them in some way (potentially as a group, or maybe to something that adapts the awaitable into an eager promise from a different system) for them to even start executing.

pizza 5y ago

Would love a programming language where optional pre- and post-invariants were a first-class language feature. So each line could be: <pre-invariants> | <line of code> | <post-invariants>. Then just let the compiler figure out the optimal ordering of things, figure out which things can be async automatically, and also perhaps this could be a built-in IDE static analysis tool to help catch logical errors earlier ¯\_(ツ)_/¯

jerf 5y ago
You can get something like that in Haskell. Functions are piles of statements that you can generally write in any order, and the compiler will deal with the resolution. You don't see this effect very strongly in Haskell though because you generally end up with small functions that don't have that many statements anyhow. (If one is sort of vaguely familiar with Haskell and thinking "what about do notation?" (or, less correctly but to the same point, "what about monads?") the answer is that do notation is a syntax sugar for introducing functions in a slightly different manner, using "<-" and some syntax transformations, so "do notation" is not a function but a function per <- symbol. Do notation affords tons of very small functions.) "figure out which things can be async automatically" If you want this, learn Go or Erlang (or Haskell). Personally I find having to manually label and deal with sync vs. "async" functions intolerable, but, fortunately, I don't have to. At the very least, though, I'd like a type system to help me out. This is something any type system can provide a lot of help with very easily, even sticking with manual async annotation. Getting a compile time error for sticking a promise for an int into an int would help keep a lot of this straight.

AtlasBarfed 5y ago

Wow, ten lines of pseudocode. Does anyone have any good site for ACTUAL state of the art in concurrency that discusses how go, rust, jvm, elixir, etc do things and the advantages? Node.JS is basically a single CPU using nonblocking I/O, great from the age of two to four core CPUs. But the future is dozens of CPUs working simultaneously to rapidly process the I/O that comes in from near-terabit networks and super SSDs using main memory bandwidth.

AtlasBarfed 5y ago
It looks like thread-per-core stuff like seastar (C++) and glommio (Rust) are still the state of the art, along with userland network drivers. glommio seems to be like a seda-thread-per-core using multiple rings as staged event buffers while running on dedicated cores.