Garbage from subscribing to collision events

[josemendez]

No problem, I love working with Obi what can I say!

I did change it to count yeah, I am doing another retest just in case I missed something. Would you be open to a skype screenshare or video if I e-mail it to you just so you can see what I am doing, maybe there's something wrong...Should be done with the retest in a few minutes then I can redo it all step by step either via screenshare or by vid just to show you the steps. It takes only about 2-3 minutes total.

I'm currently writing from a phone, but you can send me (support(at)virtualmethodstudio.com) a video showing the performance and a glance over your code, and I´ll take a look at it. It's quite late here, but tomorrow we can schedule a Skype meeting if all else fails.

cheers!

[writer51]

Just did a retest using unity game window stats only, each taken after 15 seconds: fps old version (108.7, 9.2ms), fps new version (64.4 fps, 15.5ms)

---

Ok I will send a link via e-mail with download to vid repeating the process, let me know what you think. Thanks and I hope you have a goodnight!

[josemendez]

Just did a retest using unity game window stats only, each taken after 15 seconds: fps old version (108.7, 9.2ms), fps new version (64.4 fps, 15.5ms)

---

Ok I will send a link via e-mail with download to vid repeating the process, let me know what you think. Thanks and I hope you have a goodnight!

Sure! I'll let you know if something catches my eye.

[writer51]

Sure! I'll let you know if something catches my eye.

Thanks, I appreciate it! I sent the video link to: obi@virtualmethodstudio.com

[josemendez]

Thanks, I appreciate it! I sent the video link to: obi@virtualmethodstudio.com

Hi Tigrero,

After watching your video and reproducing the issue, here's my conclusions:

- This only happens (to me) in very simple scenes like the one in your video, where the simulation time does not dominate the contact iteration. Once the simulation is more expensive that the contact iteration, this is not very noticeable. In more expensive scenes, the cost of iterating over contacts is shadowed by the simulation, that's why I didn't notice any performance hit.

- The culprit is ObiList's get_Item() method, which is the property getter used to access each individual contact trough the [] operator. The old code accessed the array directly, but the new one pays the price of a function call each time an element is accessed. I would however expect this to be inlined by the C# compiler and transformed into a simple array access. Why isn't this trivial optimization being done by the compiler? no idea, but the end result is that each access to the contacts array is roughly twice as expensive.

- Can this be worked around? yes, at the price of less elegant code. Instead of doing "e.contacts[i]" in CollisionEventHandler, do "e.contacts.Data[i]". This bypasses the function call and brings back the old performance. Let me know if you see the same improvement.

IMHO this is pretty ridiculous behaviour on the compiler's part. I'd like to think that once you compile the standalone version, Unity compiles with a higher optimization level enabled and inlines the call. But I have yet to test this.

let me know if this seems to improve things for you. Anyway, this shouldn't really matter except in very simple scenes, where the cost of simulation is so low that you end up profiling small things like function call costs. Remember that the impact of any given overhead on fps is much larger at high fps (over 200 fps) than at low fps. That is, the same thing that takes you from 500 to 200 fps (3ms worth of stuff), takes you from 33 to 30 fps.

[writer51]

I did some benchmarks this morning, thought you may be interested . 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!

[josemendez]

I did some benchmarks this morning, thought you may be interested . 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 .

As I suspected (thank you C# gods) 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).

[writer51]

Wow! thanks for such thorough profiling .

As I suspected (thank you C# gods) 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 being slightly slower (0.02 ms) 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 it is still faster for me).

Agreed, case closed on this. In almost all situations the benefit of removing GC far outweighs the microperformance gain. I think this would really shine in mobile where GC is likely even more important. I'm still not 100% convinced the original code should be removed from future updates, as a suggestion, maybe a toggle would be better? It was slightly unnerving to see my fps in editor go from 120 to 70 on a more complex scene. However, I leave the design/organization to the better minds at Obi. I appreciate all the help!

[mimarilker]

Agreed, case closed on this. In almost all situations the benefit of removing GC far outweighs the microperformance gain. I think this would really shine in mobile where GC is likely even more important. I'm still not 100% convinced the original code should be removed from future updates, as a suggestion, maybe a toggle would be better? It was slightly unnerving to see my fps in editor go from 120 to 70 on a more complex scene. However, I leave the design/organization to the better minds at Obi. I appreciate all the help!

I am exactly agreed with you on the performance drop with the newer update. I reverted back to OBI 3.2 immediately