[Mono-bugs] [Bug 655380] String switch statement 2x slower if compared to simple list of if statements

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=655380

https://bugzilla.novell.com/show_bug.cgi?id=655380#c14


--- Comment #14 from Mantas Puida <mantas at unity3d.com> 2010-11-23 14:29:06 UTC ---
I run the same test on 1st generation "iPod touch" and results are even worse:
switch statement : ~4.0-6.0 ms
if statement : ~0.33 ms

I feel like there is need to additionally explain why few milliseconds are
important for us. These tests are extracted from real world example. 

Imagine 3D game running on this iPod touch, game has ~100 C# based gameobjects
(some of them are active and rendering on screen some are not). Users typically
use some string property to "tag" object role and discriminate one gameobject
from another. Image that you have 25 objects of type "EvilEnemyType1", 25 of
type "EvilEnemyType2", etc. 

Every frame runs the code which iterates through all these 100 gameobjects and
make switch by "tag" property. And if the type is "EvilEnemyType1" then code A
should be executed and so on.

If you want nice looking and responsive game you usually aim 30 FPS, which
translates to 33 ms budget per frame, so if your code loosing 4-6 ms for switch
statement alone (versus 0.33 ms) then you are in a trouble, because it is ~20%
of CPU budget for single frame, which you probably would like to spend on
physics or processing more stuff for rendering (like skinning animated meshes).

I understand that using ints as "tag" property would solve most of these
problems, but there are several thousands .NET developers in the wild, who are
making games for iPhone. It is not an easy task to educate all of them how
write well performing code, especially when some magic is happening behind the
scenes. If compiler (gmcs or JIT) could improve performance out of the box it
would be very nice.

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.