7 ms·

That’s really interesting —- looks like there is a clear winner. I am curious as to why non blocking is slower. I also wonder if the reactive libraries could b

by pylua 3y ago

That’s really interesting —- looks like there is a clear winner. I am curious as to why non blocking is slower. I also wonder if the reactive libraries could be refactored to use the virtual threading model. It would help with a lot of the debugging issues. I would be sad to see those libraries go by the wayside as they do make a lot of complicated tasks simpler once you understand it.

brabel 3y ago
I would think the old async stuff is slower because it intrinsically requires much more memory allocation as you need to create objects and store state for everything. If you used Virtual Threads under the hood, those problems would not just disappear.
- cogman10 3y ago
  It's usually a wash, maybe even a little against virtual threads as they have to store stack information along side all the state for the current context. One of the major changes to the JVM to make virtual threads work revolved around setting up the stack to be as light weight as possible.
cogman10 3y ago
It was only slightly slower. (Netty vs virtual threads) that could easily just come down to implementation differences. The take away, IMO, is that without major architecture you can use blocking code and get near (and sometimes over) the same performance as you'd get with non-blocking code. > I also wonder if the reactive libraries could be refactored to use the virtual threading model. You could, but ultimately the question is "why?". One of the benefits of virtual threads is that the reactive model isn't as appealing. That said, it's definitely possible for the reactive libraries to simply use virtual threads whenever they do anything in parallel. That'd allow the model to avoid potential issues when calling into blocking code. There might be a better avenue in the future if the JDK devs expose the underlying coroutine API (or parts of it) that powers virtual threads today. > I would be sad to see those libraries go by the wayside as they do make a lot of complicated tasks simpler once you understand it. The benefit of virtual threads is making things even simpler so you don't need to understand those complicated constructs. You just spawn new threads whenever you need to run things in parallel.
- pylua 3y ago
  > It was only slightly slower. (Netty vs virtual threads) that could easily just come down to implementation differences. I think this might be it. After my post I thought about it and guessed that maybe the workload was potentially not an optimal netty workload, or there are aspects to the workloak that are not well suited for netty. I am unsure, however. > That said, it's definitely possible for the reactive libraries to simply use virtual threads whenever they do anything in parallel. That'd allow the model to avoid potential issues when calling into blocking code. Definitely would be a great enhancement for the elastic thread pool. > The benefit of virtual threads is making things even simpler so you don't need to understand those complicated constructs. You just spawn new threads whenever you need to run things in parallel. Once you get used to it, in my opinion, those constructs are simpler and easier to use than the standard multithreading options in java, specifically flux and timed operations. However, some items like request scope or session scope is a problem and harder (impossible?) to do right.

by pylua 3y ago

brabel 3y ago

I would think the old async stuff is slower because it intrinsically requires much more memory allocation as you need to create objects and store state for everything. If you used Virtual Threads under the hood, those problems would not just disappear.

cogman10 3y ago
It's usually a wash, maybe even a little against virtual threads as they have to store stack information along side all the state for the current context. One of the major changes to the JVM to make virtual threads work revolved around setting up the stack to be as light weight as possible.

cogman10 3y ago

It was only slightly slower. (Netty vs virtual threads) that could easily just come down to implementation differences. The take away, IMO, is that without major architecture you can use blocking code and get near (and sometimes over) the same performance as you'd get with non-blocking code. > I also wonder if the reactive libraries could be refactored to use the virtual threading model. You could, but ultimately the question is "why?". One of the benefits of virtual threads is that the reactive model isn't as appealing. That said, it's definitely possible for the reactive libraries to simply use virtual threads whenever they do anything in parallel. That'd allow the model to avoid potential issues when calling into blocking code. There might be a better avenue in the future if the JDK devs expose the underlying coroutine API (or parts of it) that powers virtual threads today. > I would be sad to see those libraries go by the wayside as they do make a lot of complicated tasks simpler once you understand it. The benefit of virtual threads is making things even simpler so you don't need to understand those complicated constructs. You just spawn new threads whenever you need to run things in parallel.

pylua 3y ago
> It was only slightly slower. (Netty vs virtual threads) that could easily just come down to implementation differences. I think this might be it. After my post I thought about it and guessed that maybe the workload was potentially not an optimal netty workload, or there are aspects to the workloak that are not well suited for netty. I am unsure, however. > That said, it's definitely possible for the reactive libraries to simply use virtual threads whenever they do anything in parallel. That'd allow the model to avoid potential issues when calling into blocking code. Definitely would be a great enhancement for the elastic thread pool. > The benefit of virtual threads is making things even simpler so you don't need to understand those complicated constructs. You just spawn new threads whenever you need to run things in parallel. Once you get used to it, in my opinion, those constructs are simpler and easier to use than the standard multithreading options in java, specifically flux and timed operations. However, some items like request scope or session scope is a problem and harder (impossible?) to do right.