Memory footprint

[AIAndy]

I have been investigating memory usage a bit.

From what I can see, cities and units have some optimization potential but they should be smaller than 100MB in total even when there are loads of units and cities around. That can also be seen in the savegames that are quite small.

The XML info classes can use optimization in parts but that will not gain more than several MBs (maybe 10s of MB).

I have not investigated what Python uses but I don't expect too excessive memory usage there (at least not beyond the basic footprint you get when you start a new game).

In the end I suspect that the majority of the memory is used up by 3d models. Especially in late game there can be an excessive amount of different units, buildings and other graphics.

I would suggest to make sure that only units from 1-2 ages are present and elder units that have an upgrade are either force-upgraded or destroyed.

 

[strategyonly]

I would suggest to make sure that only units from 1-2 ages are present and elder units that have an upgrade are either force-upgraded or destroyed.

As Arty Johnson of "Laugh-In" would say, "Very Interesting."

And your proposal would be to (example pls)

 

[AIAndy]

As Arty Johnson of "Laugh-In" would say, "Very Interesting."

And your proposal would be to (example pls)

When you reach the end of the ancient age, remove or force upgrade all prehistoric units (that have a newer unit to upgrade to).
And so on with the newer eras.
Remove the units of era X when you reach the end of era X + 1.

When you have any unit that uses a particular model in your current game, regardless of if you see it or not, the game has to have that model loaded (and likely always keeps it in memory).
And removing the obsolete units is the easiest thing to do.

 

[Jonaleth]

But wouldn't that mean the death of the infamous "Spearman-vs-Tank" scenario that Civ4 is famous for?

 

[JosEPh_II]

So my Hiawatha, which I got around 1400AD, "could" be a potential source of trouble now that I'm at game year 2010AD.

What about my pet eagles, kangaroos, panthers, tigers, and lions that I captured and have had sitting on my borders in sentry mode? Some of them were captured 100's (maybe even 1000 game yrs) of game years ago.

These random scrolling CTDs on the main screen and using the minimap are starting to frustrate me badly.

JosEPh

 

[AIAndy]

So my Hiawatha, which I got around 1400AD, "could" be a potential source of trouble now that I'm at game year 2010AD.

What about my pet eagles, kangaroos, panthers, tigers, and lions that I captured and have had sitting on my borders in sentry mode? Some of them were captured 100's (maybe even 1000 game yrs) of game years ago.

These random scrolling CTDs on the main screen and using the minimap are starting to frustrate me badly.

JosEPh

Not the age itself matters. I just suspect that too many models at the same time might cause the large amount of memory that is used up.

It might also cause problems with the graphics card. When you scroll or use the minimap, other models are shown which might require unloading a model from the graphics card and loading another one there if you run out of graphics memory. Maybe there is a bug in the Civ engine there as I doubt that has been thoroughly tested given the normal amount of models in vanilla Civ that are around at a time.

 

[JosEPh_II]

I bought a new video card before Christmas to address the Random CTD's that v19 had at start up. After your 12-16-2011 .dll patch on vanilla v19 they disappeared.

But I have since started using the SVN. Version 1384 is the version I'm using. Now that I have reached late Industrial age random CTDs are showing up again. All the minidumps I've posted have been about scrolling the Main map, the minimap, and alt tabbing in an out of the game.

My new card has 2GB of DDR3 ram on board and my main ram is 8GB of 1066Mhz DDR2. Hopefully this much ram would not allow a Graphics CTD or problem. BUt I'm going to change my settings in the Graphics Options screen for the game to medium and see what happens.

JosEPh

 

[AIAndy]

I bought a new video card before Christmas to address the Random CTD's that v19 had at start up. After your 12-16-2011 .dll patch on vanilla v19 they disappeared.

But I have since started using the SVN. Version 1384 is the version I'm using. Now that I have reached late Industrial age random CTDs are showing up again. All the minidumps I've posted have been about scrolling the Main map, the minimap, and alt tabbing in an out of the game.

My new card has 2GB of DDR3 ram on board and my main ram is 8GB of 1066Mhz DDR2. Hopefully this much ram would not allow a Graphics CTD or problem. BUt I'm going to change my settings in the Graphics Options screen for the game to medium and see what happens.

JosEPh

The problem is that we can only guess what the reason is as we have no access to the graphics engine code in the exe.
The random CTDs in V19 were due to a problem in the DLL code which we can fix.

It might be a bad model or bad handling of a lot of models or ...

 

[Koshling]

The problem is that we can only guess what the reason is as we have no access to the graphics engine code in the exe.
The random CTDs in V19 were due to a problem in the DLL code which we can fix.

It might be a bad model or bad handling of a lot of models or ...

ANyway, it's not graophics card memory that (seems to be) at issue. Its the overhead in regular memory of these models (the models are processed in GPU territory but stored in CPU territory), so it all comes back to the fact that the app is 32 bit in the end (and the game doesn't appear to demand load/page models to/from disc)

 

[AIAndy]

ANyway, it's not graophics card memory that (seems to be) at issue. Its the overhead in regular memory of these models (the models are processed in GPU territory but stored in CPU territory), so it all comes back to the fact that the app is 32 bit in the end (and the game doesn't appear to demand load/page models to/from disc)

In regards to the memory footprint I agree, hence the suggestion to reduce the amount of models active at a given time.

But Joseph was referring to the D3D crashes that happen regularly in certain circumstances when you scroll. And scrolling means that the GPU might have to show different models and since I don't expect that it keeps all textures stored in GPU memory it will require some transfers which might be buggy. It depends on how Civ handles graphics.

 

[JosEPh_II]

Here's another one from just scrolling diagonally across the main map.

More detail: The game was in the process of going through each unit. I jumped out of 1 city to go down to another that was under attack. Thus breaking the "set" pattern BtS has for going thru each active unit. Normally this has not been a problem in the past. But, thru v19 it has become a problem.

I also just updated my SVN version to this mornings version 1495 (?). And since I originally had Israel as a neighbor (and SO took it back out) I had several Non_Fatal warnings at start up. It eventually switched Israel to America. But it took an Alt Tab out and then Task manager "switch to" to get back in.

It also wanted me to "update" the game because "DLL or Assets have changed" since last time played. I did and boy was that a Big Mistake! Now I have Rampant hunger, I lost Torpedo Boats and am back down to pre dreads while the AI is hammering me with Battlecruisers and Destroyers.

This is the farthest I've yet to make it in a C2C game. I just can't seem to get and keep past the year 2012AD on Epic.

JosEPh :/

 

[Dancing Hoskuld]

When you reach the end of the ancient age, remove or force upgrade all prehistoric units (that have a newer unit to upgrade to).
And so on with the newer eras.
Remove the units of era X when you reach the end of era X + 1.

When you have any unit that uses a particular model in your current game, regardless of if you see it or not, the game has to have that model loaded (and likely always keeps it in memory).
And removing the obsolete units is the easiest thing to do.

All good in theory but the AI hardly ever upgrades units as far as I can see. This is especially true of the barbarian cities.

 

[AIAndy]

Here's another one from just scrolling diagonally across the main map.

Same as the others: The crash is in D3D9.dll which means graphics issue.
Does wild clicking around the minimap trigger it reproducable for you?
What you could try then is removing some of the unit types and see if it still happens.

@DH: Well, you can force it to and keep the barbarians halfway up to date as well.

 

[Koshling]

I have done some detailed tracing of memory allocation, and these are the conclusions:

1. Most allocation is done outside the DLL after the game state is loaded, but before it shows as ready to the user. During this time the game engine is repeatedly querying the DLL for feature and terrain details of EVERY plot, and for each it seems to loop over all possible improvments (judging by the fact it asks how many improvements there are once per plot it processes!)
2. There is rather more memory being gobbled up by plotGroups (which are trade network regions) within the DLL than I would have expected
3. Python initialisation accounts for close to 100M (in my test game, for which the total post-load footprint is over 2G)

My best guess is that the game engine is storing something for every possible improvement that COULD exist for every plot!! This strikes me as pretty dumb, but it's out of our control - the take-away is that memory usage likely scales linearly with map area (not really a major surpirse), but also has a significant component that is linearly proportional to the number of improvement types defined.

The amount being used by plotGroups may well be attackable in the DLL (and I'll look into that). However, at best it's likely to yield 50-100M total.

The Python might be slightly trimmable, but it's not accounting for enough that we can probably have a good return on effort there.

If we wanted to get really adventurous then we could consider making the improvement ids used at runtime a dynamically allocated set that is a sparse mapping of the actual full set, so that only those that are USED get reported to the game engine. For that to work we'd have to make sure that early ones auto-upgraded or obsoleted (e.g. - seed camp -> farm) unconditionally on some event (e.g. - era boundaries) regardless of whether they are being worked. That would mean that early improvements eventually drop out of use in any given game. We'd also have to cope with new ones becoming available - basically allocate a few spare slots in the dynamic set and once exhausted force the user to save and reload (which would give us the opportunity to report a different set to the game engine). Before embarking on anything that involved, more research is in order to verify the assumption that memory really is scaling with improvment count, as the call pattern suggests (which we can obviously do by adding dummy improvement types to the assets and seeing what happens to memory usage). I suspect this may be a red herring but it's worth the testing to prove it one way or another (honestly I expect to find it's really JUST map size that matters)

 

[Hydromancerx]

I personally like some of the Cowboy vs. Indians situations. I think a 1 to 2 era buffer is to small. If we still want those other situations then we need to have say Industrial (Cowboys) vs. Prehistoric (Indians) situations.

 

[JosEPh_II]

Same as the others: The crash is in D3D9.dll which means graphics issue.
Does wild clicking around the minimap trigger it reproducible for you?
What you could try then is removing some of the unit types and see if it still happens.

@DH: Well, you can force it to and keep the barbarians halfway up to date as well.

It's to the point that I'm Afraid to use the Minimap. But I'm sure I can get it to do it.

By removing unit types do you mean removing say Riflemen from ALL AI and my own? I can go into WB and remove units by using the erase map mode but that also removes the terrain improvements and features too. And if a River is on that tile then the river is borked.

Is there another way to remove unit types?

JosEPh

 

[AIAndy]

It's to the point that I'm Afraid to use the Minimap. But I'm sure I can get it to do it.

By removing unit types do you mean removing say Riflemen from ALL AI and my own? I can go into WB and remove units by using the erase map mode but that also removes the terrain improvements and features too. And if a River is on that tile then the river is borked.

Is there another way to remove unit types?

JosEPh

Remove them from the XML (or for units in modules, set the directory to not be loaded), then load the game. That should remove the units for you.

@Hydro: Different civs tend to use different models anyway so we could for starters just make sure that within one Civ only units near the current era are used.

@Koshling: Interesting. When you say "Game state loaded", I assume you mean the savegame loading is complete at that point?

 

[Koshling]

@Koshling: Interesting. When you say "Game state loaded", I assume you mean the savegame loading is complete at that point?

Yes. It's after the load that the game engine is querying the game state, and building up IT's adjunct data (whatever it is)

 

[Dancing Hoskuld]

If we wanted to get really adventurous then we could consider making the improvement ids used at runtime a dynamically allocated set that is a sparse mapping of the actual full set, so that only those that are USED get reported to the game engine. For that to work we'd have to make sure that early ones auto-upgraded or obsoleted (e.g. - seed camp -> farm) unconditionally on some event (e.g. - era boundaries) regardless of whether they are being worked. That would mean that early improvements eventually drop out of use in any given game. We'd also have to cope with new ones becoming available - basically allocate a few spare slots in the dynamic set and once exhausted force the user to save and reload (which would give us the opportunity to report a different set to the game engine). Before embarking on anything that involved, more research is in order to verify the assumption that memory really is scaling with improvment count, as the call pattern suggests (which we can obviously do by adding dummy improvement types to the assets and seeing what happens to memory usage). I suspect this may be a red herring but it's worth the testing to prove it one way or another (honestly I expect to find it's really JUST map size that matters)

There are a couple of improvements we want to get rid of as we replace features with resources eg coconut. There are also a number of improvements that are basically the same improvement on a different plant. Then there are all the prehistoric improvements we have which are very similar but we needed different ones because they upgrade to different other improvements.

I think it may be possible to get rid of 10-20 plot improvements if we can do a bit of work elsewhere eg orchard is the improvement but hover over says apple orchard.

 

[Koshling]

There are a couple of improvements we want to get rid of as we replace features with resources eg coconut. There are also a number of improvements that are basically the same improvement on a different plant. Then there are all the prehistoric improvements we have which are very similar but we needed different ones because they upgrade to different other improvements.

I think it may be possible to get rid of 10-20 plot improvements if we can do a bit of work elsewhere eg orchard is the improvement but hover over says apple orchard.

Let me do the work to confirm the theory befoer acting on it) ;-) I'll do it next week.