Speed up for short range chart

[Y A J]

Hi folks,

On my system (2.13 GHz Core 2 Duo), the short range chart is pretty slow (about 40 fps, using 100% CPU). The problem is that drawStartChart calls generateSystemData for every nearby system for every single frame, and collectively that takes an awful lot of work.

What do you think about the following alternative? Instead of recomputing everything every frame, just store the little bit of data for whichever systems are in range, and use the cached values whenever possible (which is almost always, unless the player has moved). That change drops the CPU usage for me to 45% and ups the frame rate to 75 fps (my monitor vsync rate).

I have a patch to GuiDisplayGen.m, but it's a little bit big, so I've put it here:

http://oolite.pastebin.com/f485c4638

Bye for now,
- Yet Another Jameson

[another_commander]

It''s going in. Good job Y A J and please check your PMs.

[Screet]

On my system (2.13 GHz Core 2 Duo), the short range chart is pretty slow (about 40 fps, using 100% CPU).

Thanks for fixing that!!!

What astonishes me is the speed difference - on my Phenom 9500 with 4 x 2.2 GHz it often went down to around 14fps - maybe some oxp's further slow down the process massively?

Anyway, it's the only screen I remember to slow things below vsync rate, so I'm very happy now!

Screet

[Griff]

We should get a little graphic of the 'Milk Tray' man's calling card for Y A J posts, he slips in through the window, leaves behind a patch for the oolite code then ski's off down a snowy mountain side

[Micha]

Considering the cache consists of 256 entries anyway, why not just cache the system data for the entire current map for the duration of the gaming session anyway?

ie: something like this in Universe.m:

Code: Select all

static struct saved_system
 	{
		int seed_d, seed_b;
		int tec, eco, gov;
		NSString* p_name;
	} nearby_systems[ 256 ];

struct saved_system * getSysInfo(int x)
{
  if( saved_system[x].seed_d == -1 ) // or a specific isComputed flag
  {
    <compute and store system info>
  }
  return saved_systems[x];
}

Only time you'd need to flush it is on Gal-Jump. This way you'd get the cache bonus everywhere, not just in the local map.

[Y A J]

It''s going in.

Thanks, a_c!

Considering the cache consists of 256 entries anyway, why not just cache the system data for the entire current map for the duration of the gaming session anyway?

Ah, good point. The existing generateSystemData claims to obtain a 80-95% hit rate with its single system cache, so there might not be much scope for improvement, but I'll have a look in case it helps things elsewhere.

Thanks,
- Yet Another Jameson

[Eric Walch]

Considering the cache consists of 256 entries anyway, why not just cache the system data for the entire current map for the duration of the gaming session anyway?

Ah, good point. The existing generateSystemData claims to obtain a 80-95% hit rate with its single system cache, so there might not be much scope for improvement, but I'll have a look in case it helps things elsewhere.

Thanks,
- Yet Another Jameson

With your current patch my FPS rate on that screen rose from about 30 to 100 FPS . And 100 is about the maximum I generally can get so any further improvement won't be so significant.
Great job YAJ

[Micha]

My suggestion would not improve that screen further; rather, my thinking was that if we reserve that much memory anyway, then we might as well keep all the calculated data and possibly use it elsewhere as well.

Alternatively, reduce the size of the cache - we'll never have 256 systems in the local chart.

[Kaks]

Only time you'd need to flush it is on Gal-Jump. This way you'd get the cache bonus everywhere, not just in the local map.

You're forgetting all the times the system data is changed via script: unless you explicitely flush the cache for the altered system, you'll have out of date info sitting in the cache.

Things that can be altered dynamically by any oxp at any time: system name, government type, population, tech level, etc, etc....