OpenRA/OpenRA — pull request #5433 by RoosterDragon (2014-05-24 17:11:22+00:00)
Title: Reduce memory allocations in the main loop.

# Memory

I targeted some methods allocating memory in the main loop and tweaked them. They function the same - just with less allocations.

Tested in RA for 2 ingame minutes on a 4 player map with 4 rush bots.

## Before
1218 MiB allocated in total

| Method | Allocated (MiB) |
| --- | ---: |
| Actor.Render | 45 |
| FrozenUnderFog.Tick | 112 |
| FrozenActor.Tick | 112 |
| Widget.GetEventBounds | 31 |
| Animation.Render | 66 |
| MobileInfo.CanEnterCell | 2 |
| *HardwarePalette.ApplyModifiers* | 86 |
| *PerfTimer overhead in DoTimed* | 500 |

The latter two methods I didn't alter in this PR, but they're useful to include as a reference point.

## After
939 MiB allocated in total

| Method | Allocated (MiB) |
| --- | ---: |
| Actor.Render | 0 |
| FrozenUnderFog.Tick | 0 |
| FrozenActor.Tick | 0 |
| Widget.GetEventBounds | 0 |
| Animation.Render | 31 |
| MobileInfo.CanEnterCell | 0 |
| *HardwarePalette.ApplyModifiers* | 91 |
| *PerfTimer overhead in DoTimed* | 474 |

Of the methods I targeted that's 368 MiB reduced to 31 MiB.

# CPU
As a pleasant side effect this also reduced the CPU time spent in some methods.

Tested in RA for 8 ingame minutes on a 4 player map with 4 rush bots.

## Before

| Method | Relative Time (%) |
| --- | ---: |
| Actor.Render | 2.46 |
| FrozenUnderFog.Tick | 3.00 |
| FrozenActor.Tick | 2.24 |
| Widget.GetEventBounds | 0.82 |
| Animation.Render | 2.70 |
| MobileInfo.CanEnterCell | 1.11 |
| *HardwarePalette.ApplyModifiers* | 5.23 |
| *PerfTimer overhead in DoTimed* | 12.91 |

## After

| Method | Relative Time (%) |
| --- | ---: |
| Actor.Render | 1.78 |
| FrozenUnderFog.Tick | 1.55 |
| FrozenActor.Tick | 0.51 |
| Widget.GetEventBounds | 0.09 |
| Animation.Render | 1.16 |
| MobileInfo.CanEnterCell | 0.77 |
| *HardwarePalette.ApplyModifiers* | 4.43 |
| *PerfTimer overhead in DoTimed* | 13.07 |

That's a reduction from 12.33% to 5.86%. There might also be some reduction in GC time since there's less garbage to collect - I have no numbers for that though.

As a quick aside, the PerfTimer change that resulted in its poor performance happened after I drafted up this set of changes hence why it's not in this PR. See #5408 for a change that should fix most of the allocation and some of the CPU time.