(21-04-2020, 05:20 PM)josemendez Wrote: Internally, each solver spawns multiple tasks that get attended by a task scheduler (thread pool). Each actor is decomposed into a few tasks, but it does not matter if they are all under same solver or separate solvers as the tasks end up being exactly the same. So one solver does the same work as multiple ones, as it all comes down to tasks and a thread pool.
Just to test this, do you see any performance difference if you have the 50 particle rope and the 3 particle rope under the same solver, as opposed to having a solver for each one?
Yes - I just tested this hypothesis.
Two pair of ropes under two solvers vs two pair of ropes under same solver. (A pair is still a rope with a loop on the end).
Two Solvers unity profiler data from build on Quest; https://easyupload.io/lm96le
Roughly 50 frames on average.
One shared Solver unity profiler data from build on Quest; https://easyupload.io/9qs98l
Almost stable lock at 72 frames.
(Edit; i also removed some disabled solvers from the updater, so there was only one solver in the updater compared to 8 solvers in the first test)
Exactly same amount of particles.
[EDIT]
The worst spike of obiFixedUpdate lies on 3.27ms on one solver vs. the >10ms on two.
It would be nice if you could confirm this, because I have to change a lot of my code base to put all ropes under one solver which is gonna take a long time.
[EDIT 2]
Maybe I could circumvent the redesign by putting each solver in its own fixed updater and turning those off instead? Currently they are all under the same updater.
[EDIT 3]
Can confirm disabled solvers in an updater still takes up a lot of resources apparently.