3 ms·
In my experience, for most jvm apps non blocking io is a premature optimization that makes little performance difference. I once optimized an app, for instance,
by sreque 8y ago
In my experience, for most jvm apps non blocking io is a premature optimization that makes little performance difference. I once optimized an app, for instance, by switching to non blocking io, and was only able to go from 1000 rps percore to 1200. I got a better performance improvement by switching out the service's json library for a faster one, and that took far less effort.
For the most part, I see non blocking io as a fad. It can make a noticeable difference in Performance, but in practice most apps are so poorly optimized that there are easier, lower+hanging fruit.
- yashap 8y agoFair enough, threads are indeed cheaper than many realize, even JVM threads, which are basically OS threads. But projects where I use Scala do tend to include a lot of service calls that are worth making concurrent (for example, hitting 3 services at once for a single request, or looking up 20 entities at once from a service that doesn’t have a bulk endpoint). And if you’re going to wrap this library with future calls, properly configure your threadpool, etc., you may as well have just used the very mature Play WS, and also get better efficiency. The APIs are pretty similar aside from Play WS returning Futures.