07-06-2021, 07:56 AM
(This post was last modified: 07-06-2021, 08:07 AM by josemendez.)
Hi there,
I assume the jobs are stored as members of the BurstDistanceConstraintsBatch class, right? I tried this approach on distance and bend constraints, then ran all performance tests: doesn't make any measurable difference for me on any scene (ms/frame or FPS). Also used profiler sampling, but timings were pretty similar for both approaches. Storing the jobs as members saved around 0.005 ms/substep on average, but this is hard to say for sure since timing varies between frames. It's certainly not as large as 0.1 ms per projection as your profiler pic shows, maybe there's something else going on?
The only overhead of the current code is creating the job struct once per projection, which should be negligible in most cases as creating a single struct is pretty cheap. Regardless, I will push this change to production as any performance boost is welcome no matter how small. Will ship in Obi 6.2.
Thanks for sharing!
I assume the jobs are stored as members of the BurstDistanceConstraintsBatch class, right? I tried this approach on distance and bend constraints, then ran all performance tests: doesn't make any measurable difference for me on any scene (ms/frame or FPS). Also used profiler sampling, but timings were pretty similar for both approaches. Storing the jobs as members saved around 0.005 ms/substep on average, but this is hard to say for sure since timing varies between frames. It's certainly not as large as 0.1 ms per projection as your profiler pic shows, maybe there's something else going on?
The only overhead of the current code is creating the job struct once per projection, which should be negligible in most cases as creating a single struct is pretty cheap. Regardless, I will push this change to production as any performance boost is welcome no matter how small. Will ship in Obi 6.2.
Thanks for sharing!