search

conversant / disruptor

Disruptor BlockingQueue
Apache License 2.0
311 stars 47 forks source link

Performance in virtual threads #64

Closed DanielYWoo closed 9 months ago

DanielYWoo commented 9 months ago

Hi,

As JDK gradually shift from platform threads to virtual threads, some of the optimization probably are not needed in the future. What's the roadmap of this project and change for the virtual threads? Do we have a performance analysis or something for virtual threads?

Thanks, Daniel

jac18281828 commented 9 months ago

Thanks for the intriguing question, @DanielYWoo. Like you, I'm curious about the performance differences between virtual threads and platform threads. If you have practical examples or experiences please do share them here!

Virtual threads are ideal for handling a large number of short-lived threads without prioritizing low latency or high throughput. This is because virtual threads share the compute resources overall. In contrast, applications seeking high throughput often use long-lived platform threads as dedicated workers for spinning or polling workloads. In this scenario the platform threads are carefully orchestrated so as not to share the compute resources. This approach aligns well with the main use case for Java's BlockingQueue. In general, there is not much intersection between the two models.

As far as performance analysis, this type of analysis belongs to the applications implementing these technologies and not the project itself. Each application will have its own unique characteristics and requirements for a threading model. Most applications will perform great with virtual threads and likely never spin the processor for any reason.

If incorporating virtual thread support can enhance any part of this project, feel free to submit a PR. The community would surely appreciate it!