fighters on "patrol" = performance hit

[zerver]

This reduces the CPU usage for 1500 patrolling fighters by ~50%:

http://github.com/spring/spring/commit/ ... 7d6a7241db

[aegis]

caches recent hits in the same area so the separate units effectively share lookups?

[thesleepless]

looks like it! nice

[Tobi]

This reduces the CPU usage for 1500 patrolling fighters by ~50%:

http://github.com/spring/spring/commit/ ... 7d6a7241db

Lol, what had you been smoking when making this?

I pretty much said exactly how the functions could be improved, and the code needed for this was already present in GenerateTargets... no need for cache at all.

I implemented this now, and it's more then twice as fast as your caching solution, without making the algorithm inexact and without adding new code (everything I used was already present in GenerateTargets.)


Timing results

This is total time spent in CGameHelper::GetClosestEnemyUnit and CGameHelper::GetClosestEnemyAircraft, in a game using BA 7.00 on Bluebend, 1500 armhawks.

Manual test:

Code: Select all

2 min game, 1 min patrol, original: 17.70 sec
2 min game, 1 min patrol, zerver  :  4.89 sec
2 min game, 1 min patrol, Tobi    :  1.58 sec

Test using replay, so 100% identical game each time:

Code: Select all

3 min game, 2 min patrol, original: 30.05 sec
3 min game, 2 min patrol, zerver  :  5.05 sec
3 min game, 2 min patrol, Tobi    :  2.47 sec

EDIT: ok, maybe on long term (after 17 minutes on exactly same patrol route, follows from simple linear extrapolation) yours might be slightly faster, as I got this for 10 minutes:

Code: Select all

10 min game, 9 min patrol, zerver: 12.37 sec
10 min game, 9 min patrol, Tobi  : 10.99 sec

(But OTOH, my optimization also helps ground units and Lua gadgets that use GetClosestEnemyUnit, which aren't considered in this test.)

[ginekolog]

Nice one Tobi, figter patrols are biggest causes of lag in big games :)

[Pendrokar]

Tobi : Zerver
2 : 1

Let the competition really begin!!! Competition => Progress

[Beherith]

Thank you both (Tobi and zerver) for adding a great performance improvement!

[hunterw]

this game is so awesome

if only more ppl played it

[zerver]

This reduces the CPU usage for 1500 patrolling fighters by ~50%:

http://github.com/spring/spring/commit/ ... 7d6a7241db

Lol, what had you been smoking when making this?

I pretty much said exactly how the functions could be improved, and the code needed for this was already present in GenerateTargets... no need for cache at all.

EDIT: ok, maybe on long term (after 17 minutes on exactly same patrol route, follows from simple linear extrapolation) yours might be slightly faster, as I got this for 10 minutes:

So just because you say how to improve it, I have to follow orders? I didn't smoke anything and the caching can be even faster - just increase the cache expiration time.

[imbaczek]

lkml-class flamewar on the horizon, captain! /me dons asbestos suit

[Tobi]

This reduces the CPU usage for 1500 patrolling fighters by ~50%:

http://github.com/spring/spring/commit/ ... 7d6a7241db

Lol, what had you been smoking when making this?

I pretty much said exactly how the functions could be improved, and the code needed for this was already present in GenerateTargets... no need for cache at all.

EDIT: ok, maybe on long term (after 17 minutes on exactly same patrol route, follows from simple linear extrapolation) yours might be slightly faster, as I got this for 10 minutes:

So just because you say how to improve it, I have to follow orders? I didn't smoke anything and the caching can be even faster - just increase the cache expiration time.

If it's arguably the best / a better thing to do to the code, then it's a bit silly IMO to implement a suboptimal solution, in particular if the better solution is handed to you on a silver platter (both in my posts and in the existing CGameHelper::GenerateTargets code; I only had to copy paste it to implement my code)...

Sorry if I offended you with the joke about smoking though

[zerver]

1500 fighters in DSD style patrol pattern:

Mine: 57% cpu.
Yours: 63% cpu.
Mine+yours: ?

Sorry to disappoint you, but there wont be any flamewar.

[Argh]

Yeah, I want to see the peanut and jelly together before reading more flames.

Moreover, I'm more interested in what happens when you split that 1500 fighters into 10 groups on different paths. It's been my experience that the slowdown in Patrol is when you have aircraft all over the Map... not some ridiculous bunched-up cluster.

[zerver]

Like tobi said, my solution wont be that good if the patrol routes are random or complicated...

[Argh]

Yours will help with the cluster- for raids where Patrol gets used as the control parameter. That's fine- there is a point to that, for gunships especially. I'm just saying... the main clobberin' time is when you have factories on Repeat, building fighters on long, complex Patrol paths, as a for-instance.

[Tobi]

Both solutions reduce the number of units visited immensely. Zerver's reduces it -after one call- by the number of allied units in every quad in the search space which does not contain any enemy units. Mine reduces it unconditionally by the number of allied units in the search space, though it adds a tiny constant overhead per quad (a loop through all allyteams).

Combined solution probably wouldn't help much, as then you're caching the result of the best running time case of GetClosestEnemyUnit/Aircraft. (Only looping through all allyteams and observing none of the enemy allyteams have any units in that quad.)

[zerver]

Combined solution probably wouldn't help much

I have confirmed that, it seems now that other things are predominant in hogging up the CPU.

[Dragon45]

Lol, what had you been smoking when making this?

Nice zinger there, Linus Shaw Hannson.

[hoijui]

thanks you two!
fighterscreens are really the killer of my machine, and i was usually not alone with this in average till big games.

[Soul]

A slight offtopic post, but LOS was mentioned eariler so its only a small sin.

Does anyone know if every unit have their LOS overlapping eachother, or if one units LOS "ends" where another units LOS begin?

And yes, i'm not stupid, the LOS overlapping would be the most probable, but I still want to be certain.

I'm not saying that making LOS end where another units LOS begins would draw down the CPU usage, most likely the opposite (due to the additional code that needs to be processed).


Oh, and to make this post slightly more on track: Wasn't fighter spam nerfed like ages ago? I remember NOiZE killing my com with a handfull fighters one day, while I couldn't even hurt his commander below 80%HP with twice the amount of figthers after the nerf.
And he was like "Dude, didn't you read last nights patchlog?"