Compiler and DLL output file size questions

[Afforess]

I've always wondered, since I use codeblocks to compile Civ4's dll, is there any major differences to codeblocks and VS2008?

Also, I've noticed that when I compile RevDCM's sources I get DLL files that are roughly 7.5mb But the DLL's in RevDCM are 5.5mb. I've always assumed that this was because I compiled to with maximum speed and Jdog probably compiled to minimize file size. But, does this make any difference when playing a game?

 

[xienwolf]

No difference, each of those is just a pretty GUI essentially. There are commands which they share to achieve the exact same compilation in the end. It is those commands which matter. I would say that a 7.5mb DLL possibly has the Profiler enabled, while a 5.5mb is a standard final release construction. Both VS and Codeblocks can achieve either one (something around 9mb would typically be a debug DLL, or otherwise have all Asserts and profilers enabled)

Basically the difference between compiling with Codeblocks or VS is the difference between coming to these forums with Internet Explorer or Firefox. Both show you the same site, it is your settings in the logged account which determine how things look and behave primarily.

 

[Afforess]

I would say that a 7.5mb DLL possibly has the Profiler enabled, while a 5.5mb is a standard final release construction. Both VS and Codeblocks can achieve either one (something around 9mb would typically be a debug DLL, or otherwise have all Asserts and profilers enabled)

Forgive my ignorance, but I'm relatively new to these things. Does having the profiler enabled make any difference in the game? Does it run slower?

 

[xienwolf]

Runs very slightly slower, but enables the profiler, which is used to identify where your speed is being sapped so you can fix it.

 

[Afforess]

Runs very slightly slower, but enables the profiler, which is used to identify where your speed is being sapped so you can fix it.

Okay, how do I enable/disable the profiler in Codeblocks?

 

[xienwolf]

It is disabled by default, so one of the mods you borrowed code from had enabled it, so it really depends on how they bypassed the thing. The proper method is to declare new compiler options, but that would not have made it into your build commands (thus why it is the proper method)

In FProfiler.h there should be these lines near the top (line 16 is the first for me)

#ifndef FINAL_RELEASE
#ifndef FP_PROFILE_ENABLE 
	#define FP_PROFILE_ENABLE 
#endif
#endif

This says that if you are NOT doing a Final_Release, to enable the profiler if it was not already enabled. So you might be failing to declare yourself as a final_release, you might be choosing to enable the profiler, or you might have this FP_PROFILE_ENABLE declared somewhere else.

Starting on line 71 (in mine at least) is:

#ifdef FP_PROFILE_ENABLE				// Turn Profiling On or Off .. 
#define PROFILE(name)\
	static ProfileSample sample(name);\
	CProfileScope ProfileScope(&sample);

If the first line were to be removed then the profiler would ALWAYS be enabled.

And of course, I could be wrong.

 

[Afforess]

Hmm. My Fprofiler.h code is exactly the same as yours. I know I'm always compiling a final release, unless I'm purposely compiling a final debug, but the difference between the two is quite obvious.

See for yourself...

View attachment 228791

 

[EmperorFool]

Keep in mind that the Final_Release that is the make target is not the same thing as the FINAL_RELEASE preprocessor flag. IIRC Refar's make file defines FINAL_RELEASE within the Final_Release target, so the latter should disable the profiler.

Regarding Code::Blocks, when I was trying to help Alerum build the DLL, he started with that tool. He got it to build, but it was my understanding that CB was calling the compiler directly. This means it was ignoring the make file and thus its compiler/linker flags. There are different optimization flags, and one major component is size versus speed. There is a runtime speed difference, and it can be non-trivial. They should both operate exactly the same logically, however.

 

[Afforess]

Regarding Code::Blocks, when I was trying to help Alerum build the DLL, he started with that tool. He got it to build, but it was my understanding that CB was calling the compiler directly. This means it was ignoring the make file and thus its compiler/linker flags. There are different optimization flags, and one major component is size versus speed. There is a runtime speed difference, and it can be non-trivial. They should both operate exactly the same logically, however.

Yeah, I never had to use the make file, I loaded up the VS save file directly, and everything compiled fine. I have seen the optimization flags, and mine is set for speed, but there is a size one too.

Which one runs better, optimized for speed or optimized for size?

 

[davidlallen]

Which one runs better, optimized for speed or optimized for size?

What do you mean by "better", do you want it to run faster or take up less memory? The point is you have to make a tradeoff.

 

[Afforess]

What do you mean by "better", do you want it to run faster or take up less memory? The point is you have to make a tradeoff.

Okay, I would prefer one that runs faster, but also memory is important, because MAF errors do happen with RoM. So, it depends, how big is the speed increase vs memory factor.

 

[EmperorFool]

My bet is that the size of the DLL is not responsible for MAF errors because it is fixed. If you build a 9MB DLL, it requires exactly 9MB to load into memory. Reducing that to 5MB is going to save you exactly 4MB, and that's hardly going to save you from out of memory errors.

You need to look at RoM's source code to figure out what extra data it is storing, especially data that grows with an object type that gets created a lot, such as cities, units, and plots. Have you found any pattern to these errors? Do they occur more frequently on Huge maps, or are they more likely if you build a lot of units in the late game?

The game is also known to leak memory. This means that it allocates some memory but doesn't free it once it's done using the data it holds. If you do this enough times, you run out. Imagine throwing away your pants every time they get dirty. Soon enough you run out. If this is the cause, players could avoid them by frequently saving and restarting Civ.

 

[Afforess]

You need to look at RoM's source code to figure out what extra data it is storing, especially data that grows with an object type that gets created a lot, such as cities, units, and plots. Have you found any pattern to these errors? Do they occur more frequently on Huge maps, or are they more likely if you build a lot of units in the late game?

RoM's source code is RevDCM's, FYI.

Yes, there is an obvoius pattern. MAF occur later in the game, (AD) and more with large maps, more units...

The game is also known to leak memory. This means that it allocates some memory but doesn't free it once it's done using the data it holds. If you do this enough times, you run out. Imagine throwing away your pants every time they get dirty. Soon enough you run out. If this is the cause, players could avoid them by frequently saving and restarting Civ.

Is there a way we could fix this, buy opening up space after some functions are done, or variables are unused. Like, for instance, the game never needs to run the code to spawn animals after about 100 turns. Is there a way we can de-initialize those variables? (Forgive my poor use of terminology.)

 

[EmperorFool]

I suspect the memory leaks are in the EXE. There may be some in the DLL, and if there are you could try to find and fix them. This is more easily done with a profiling tool that will keep track of all memory allocations and deallocations so you can find what caused the leaked memory.

It's not really related to features that get used for only part of the game. All local variables are kept on the stack and freed automatically when a function exits.