Optimizing Sim Loop

[10053r]

So I was just in a 10 person game on Wide Open Combat and it was very slow. Now, you might say that this was a silly thing for me to do, but the game was very slow rather too early if you ask me. I'd say when each of us only had maybe 100 units it had slowed to a crawl.

That's only 1000 units on a 24 x 24 map. Can I request that some optimization of the engine be done such that we can support slightly larger games? Also, aircraft were turned off. The major resource hogs, according the the "b" button, were Sim Time (Number 1 offender at 33%), and Unit handler (number 2 at 25%).

I love spring, and I understand if this isn't a priority, but it would still be very nice.

[10053r]

Also, bear in mind that this was Wide Open Combat, so at 100 units per person, very little combat was happening, just the beginning skirmishes.

[IMSabbel]

Those are always the forst offenders...

(sorry about me dropping, btw. My dsl provider cut the line for maintainance at midnight for an hour :/ )

I have seen every cvs commit the last 4 months, and there was not a single one that showed that any optimisation effort was taking place... which is actually quite sensible, as optimisation during development usually means shitty garbled code in the end.
But i would be interesting in what "simtime" actually does...
... and how true those runtime-profiling values really are. I have witnessed quite some strangness when trying to profile code with really low level stuff like amd code analyst, and even then it was often missleading (like the register pressure of the temp values being updated causing the loops to become slower, ect...)

[jcnossen]

Simtime is the time is takes to do this:

Code: Select all

	helper->Update();
	mapDamage->Update();
	pathManager->Update();
	uh->Update();
	ph->Update();
	featureHandler->Update();
	GCobEngine.Tick(33);
	wind.Update();
	loshandler->Update();

	if(!(gs->frameNum&31)){
		for(int a=0;a<gs->activeTeams;++a)
			gs->teams[a]->Update();
	}
//	CPathFinder::Instance()->Update();	
START_TIME_PROFILE
	ground->CheckCol(ph);	
	ph->CheckUnitCol();
END_TIME_PROFILE("Collisions");

So it's basically all game updating.
It's also pretty high level, so I think these profiling values are very true.
I think spring is really stressing the memory manager. There are STL containers being passed around everywere, and these constantly need to be allocated and deallocated. It's just a guess though. I think it would be good to start using the memory pool (There is already a MemPool.cpp, but I don't think it's used very much) in the most performance critical parts of spring. Spring's speed has been bugging me, so maybe I'll give it a try sometime...
I wonder what SJ has to say about optimization though, care to comment SJ?

(sorry about me dropping, btw. My dsl provider cut the line for maintainance at midnight for an hour :/ )

In a completely different game though, I got the same problem, in fact, I was just about to be com-bombed and my provider fails me. So it looked like I dropped because I couldn't take a loss Anyway I just wanted to say how irritating that can be

[SJ]

Sure go ahead and optimize it if you can. But I dont think the memory manager is the biggest problems. Most high rate allocate/deallocate objects like los and projectiles already use the mempool implementation.

I havent looked that closely at what takes up the cpu now but I think los calculations takes about 1/4th of the total and is esp high with many fast units in play (like aircrafts). Pathfinding system update can seem to take a lot in the beginning but it doesnt increase with more units/action so its probably ok although it might be good. I think finding targets/seeing if they are blocked can take quite some time esp with long range units like BBs.

Well there is some stuff that might be worth looking at although there is probably others also.

[jcnossen]

Most high rate allocate/deallocate objects like los and projectiles already use the mempool implementation.

Ah ok I didn't see that.
Anyway, I'll profile some classes so we actually know what's taking all the time.
I was also thinking about writing a new template container specifically for temporary storage that can be used instead of vector. Maybe that will speed it up a bit...