-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursion on ExecutorService with >1 Thread is Slow #711
Comments
This was referenced Dec 31, 2013
benjchristensen
added a commit
to benjchristensen/RxJava
that referenced
this issue
Apr 19, 2014
Removed |
zsxwing
pushed a commit
to zsxwing/RxScala
that referenced
this issue
Aug 19, 2014
benjchristensen
added a commit
to ReactiveX/RxScala
that referenced
this issue
Aug 19, 2014
benjchristensen
added a commit
to ReactiveX/RxScala
that referenced
this issue
Aug 19, 2014
benjchristensen
added a commit
to ReactiveX/RxScala
that referenced
this issue
Aug 19, 2014
benjchristensen
added a commit
to ReactiveX/RxJavaAsyncUtil
that referenced
this issue
Aug 29, 2014
benjchristensen
added a commit
to ReactiveX/RxJavaComputationExpressions
that referenced
this issue
Aug 29, 2014
jihoonson
pushed a commit
to jihoonson/RxJava
that referenced
this issue
Mar 6, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recursion on NewThreadScheduler or ExecutorScheduler with 1 thread is fast. As number of threads increase in the pool it increasingly slows down. My guess is it's adding overhead jumping between threads and/or CPUs and thus having cache misses or something along those lines.
I found this while testing
TestRecursionMemoryUsage
and tryingSchedulers.threadPoolForComputation()
versusSchedulers.newThread()
.I confirmed that this changes the performance:
Executors.newScheduledThreadPool(2)
vsExecutors.newScheduledThreadPool(1)
The real code uses numCores for that value which is worse.
We need to look at a way of using a thread-pool sized to the number of threads on the machine so we're not launching new threads every time a scheduler is used, but that recursion efficiently uses the same thread.
The text was updated successfully, but these errors were encountered: