4 ms·

Are your users going to be running your application on laptops? Will they have the same "conserve power by limiting performance" going on? If so, that is _exa

Are your users going to be running your application on laptops? Will they have the same "conserve power by limiting performance" going on? If so, that is _exactly_ the environment you want to do performance work in, generally speaking.

jstrong 6y ago
generally speaking, the advantage of async io is strongest for high performance server applications, especially in regards to the cpu usage required relative to the amount of io stuff you can do. with that in mind, "users running your application on laptops" would not be the most common case.
- bzbarsky 6y ago
  Yes, if your app is a high performance server app, measure in that environment. But user-facing apps (the sort people run on laptops, say) have async I/O as table stakes, really. It's not even about throughput or CPU cycles: it's about the fact that if you have I/O latency on any thread the user interacts with the user experience will be terrible. Now in practice maybe that means "just make the I/O async, but the performance details of that don't really matter too much". Anyway, the overall comment was about performance profiling in general, not just async I/O.
johnsoft 6y ago
It's about having a consistent measurement baseline. Say you run your benchmark once, then thermal throttling kicks in, then you run it again, and it takes twice as long. Is your code actually slower now? Should I wait until the fan turns off before I run it again? That data is noisy and useless. Take your measurements on a server or desktop with sane thermals and a full-size fan. If you speed things up by 10% on your server, they'll get 10% faster on your laptop as well.
- bzbarsky 6y ago
  Yes, you have to be very careful with measurements, I agree. > If you speed things up by 10% on your server, they'll get 10% faster on your laptop as well. Depends on the speedup and techniques to achieve it. For example, speeding things up via more parallelism can lead to wall-clock improvements on servers but not laptops, precisely because the latter just end up doing more thermal throttling.... Ideally, you want to measure both ideal hardware and actual-user-hardware; often speedups on one will not be visible on the other and vice versa.

jstrong 6y ago

generally speaking, the advantage of async io is strongest for high performance server applications, especially in regards to the cpu usage required relative to the amount of io stuff you can do. with that in mind, "users running your application on laptops" would not be the most common case.

bzbarsky 6y ago
Yes, if your app is a high performance server app, measure in that environment. But user-facing apps (the sort people run on laptops, say) have async I/O as table stakes, really. It's not even about throughput or CPU cycles: it's about the fact that if you have I/O latency on any thread the user interacts with the user experience will be terrible. Now in practice maybe that means "just make the I/O async, but the performance details of that don't really matter too much". Anyway, the overall comment was about performance profiling in general, not just async I/O.

johnsoft 6y ago

It's about having a consistent measurement baseline. Say you run your benchmark once, then thermal throttling kicks in, then you run it again, and it takes twice as long. Is your code actually slower now? Should I wait until the fan turns off before I run it again? That data is noisy and useless. Take your measurements on a server or desktop with sane thermals and a full-size fan. If you speed things up by 10% on your server, they'll get 10% faster on your laptop as well.

bzbarsky 6y ago
Yes, you have to be very careful with measurements, I agree. > If you speed things up by 10% on your server, they'll get 10% faster on your laptop as well. Depends on the speedup and techniques to achieve it. For example, speeding things up via more parallelism can lead to wall-clock improvements on servers but not laptops, precisely because the latter just end up doing more thermal throttling.... Ideally, you want to measure both ideal hardware and actual-user-hardware; often speedups on one will not be visible on the other and vice versa.