Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Garbage from subscribing to collision events
#17
(18-12-2017, 06:10 PM)writer51 Wrote: I did some benchmarks this morning, thought you may be interested Sonrisa. The three tests I'm referring to as old code vs new code vs new code bypass. Fps test were done using advanced fps and unity stats in scene faucet and bucket (with changes shown in video). Data was taken between 1:30mins-2:30mins into the simulation

TLDR - At runtime performance is practically equivalent. If we are talking about negligible differences, the old code is still fastest despite the garbage generation.

Old Code Editor
Advanced FPS- Current: 192
Advanced FPS- Min: 179
Advanced FPS- Max: 200
Advanced FPS- Avg: 193 (5.18ms)
Unity Stats: Range- 530-610 (Rough Avg 570 - 1.7 ms)

Old Code Build
Advanced FPS- Current: 853
Advanced FPS- Min: 829
Advanced FPS- Max: 987
Advanced FPS- Avg: 849 (1.18ms)

New Code Editor:
Advanced FPS- Current: 174
Advanced FPS- Min: 169
Advanced FPS- Max: 197
Advanced FPS- Avg: 173 (5.78ms)
Unity Stats: Range 380-430 (Rough Avg 400 fps - 2.5 ms)

New Code Build:
Advanced FPS- Current: 839
Advanced FPS- Min: 823
Advanced FPS- Max: 969
Advanced FPS- Avg: 838 (1.19 ms)

New Code Bypass Editor:
Advanced FPS- Current: 187
Advanced FPS- Min: 181
Advanced FPS- Max: 205
Advanced FPS- Avg: 186 (5.38 ms)
Unity Stats: Range 470-510 (Rough Avg 500 fps - 2.0 ms)

New Code Bypass Build:
Advanced FPS- Current: 829
Advanced FPS- Min: 804
Advanced FPS- Max: 979
Advanced FPS- Avg: 826 (1.21 ms)

By averages in Editor: Original Code > New Code Bypass > New Code
By averages at Runtime: Original Code > New Code > New Code Bypass

Thank you and the Obi team for your hard work and giving us an option to minimize garbage!

Wow! thanks for such thorough profiling Sonrisa.

As I suspected (thank you C# godsÁngel) the compiler optimizes the function call away at runtime and performance is roughly the same both for the raw access/[] operator methods.

The new code still being slightly slower could be explained by the extra getter used (.Data) to get to the raw array. Calling this once at the top of the OnCollision callback, instead of calling it inside the loop, might scrape a tiny lil bit of performance back. But I'd be surprised if the compiler didn't do this automatically.

If you're ok with it, I'd say case closed. The benefit of not having GC spikes outweights these tiny performance differences (and in heavier scenes with lots of contacts, using the new method I still see performance gains).
Reply


Messages In This Thread
RE: Garbage from subscribing to collision events - by josemendez - 18-12-2017, 06:36 PM