Increasing compiling speed

stmartin

aka. poyuzhe
Joined
Aug 4, 2007
Messages
640
Location
Shanghai
On VS2008 compile the sdk through the standard makefile is pretty slow on my computer.

I noticed there's a thing called pre-compiled header. I tried to modify the makefile to enable it. But I get lots of error message.

Anyone has any idea how to enable pre-compiled header with Civ4? Or any general idea to improve compiling speed is huge to me. Thanks.
 
On VS2008 compile the sdk through the standard makefile is pretty slow on my computer.

I noticed there's a thing called pre-compiled header. I tried to modify the makefile to enable it. But I get lots of error message.

Anyone has any idea how to enable pre-compiled header with Civ4? Or any general idea to improve compiling speed is huge to me. Thanks.

If you are compiling with the standard technique in "Refar's Guide", then you are not actually *compiling* with the VS2008 compiler. You have also installed the VS2003 compiler and the makefile is calling that explicitly. You are just using the VS2008 tool as a GUI, to run "make".

So any specific VS 2008 option you turn on will not have the intended effect. I am not familiar with the documentation for VS 2003; but if you find that, and you can find command line options for precompiled headers, it may be faster.

Perhaps you already know this technique, but in general, try to avoid full recompiles. I try to make all my header changes once, then do a full compile, and then after that I can tweak the source files multiple times. Recompiling everything takes time, but if I avoid header changes, this is not needed.

In a typical sdk change project, I add new headers once and do a full recompile, say 20 minutes; then recompiling and relinking a single C file each time takes maybe 2-3 minutes. Out of that time, most of it is in the linker. I am quite sure that precompiled headers will not affect link time. I can't think of much to affect link time.
 
I am quite sure that precompiled headers will not affect link time.

Correct. A precompiled header only removes the time to parse and compile any header files in the precompiled header that are #included by a source file that needs to be compiled.

I can't think of much to affect link time.

You can specify incremental linking. This is on by default for Debug builds in Refar's makefile IIRC. Instead of rebuilding the entire lib from all the obj files, it plugs in only the changed obj files.
 
You can specify incremental linking. This is on by default for Debug builds in Refar's makefile IIRC.

I haven't tried it, but in case it isn't clear what to change, here are two lines from Refar's makefile:
Code:
Debug_LDFLAGS= $(Debug_PROJECT_LDFLAGS) /debug /NODEFAULTLIB:msvcprtd.lib /pdb:Debug\CvGameCoreDLL.pdb [COLOR="Red"]/INCREMENTAL[/COLOR] /SUBSYSTEM:WINDOWS $(Debug_GLOBAL_LDFLAGS)
Final_Release_LDFLAGS= $(Final_Release_PROJECT_LDFLAGS) /debug [COLOR="red"]/INCREMENTAL:NO[/COLOR] /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF $(Final_Release_GLOBAL_LDFLAGS)
So remove ":NO" from the final release flags line.
 
So remove ":NO" from the final release flags line.


I tried this and it didn't work, it gave me this

Spoiler :
1>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
1> Creating library Final_Release\CvGameCoreDLL.lib and object Final_Release\CvGameCoreDLL.exp
1>LINK : warning LNK4089: all references to 'KERNEL32.dll' discarded by /OPT:REF
1>The system cannot find the path specified.
1> 0 file(s) copied.
1>Build log was saved at "file://c:\Users\TheLadiesOgre\Desktop\New CvGameCoreDLL\TLOTags\CvGameCoreDLL\Final_Release\BuildLog.htm"
1>CvGameCoreDLL - 0 error(s), 2 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========


It did compile and link, just no quicker than usual
 
Just commenting here, and maybe I'm just obtuse, but who cares about compiling speed? I've never had an issue with it. It's always been about ten minutes on my laptop for a recompile...
 
When you become more proficient with programming, compilation and startup speed become more of an issue. When you make a 30 second fix, you don't want to have to wait 10 minutes to verify that it worked.

Do not specify the two /OPT options for Debug builds. Here's how I have them in BULL:

Code:
LDFLAGS = 
DEBUG_LDFLAGS = $(LDFLAGS) /debug /pdb:Debug\CvGameCoreDLL_DEBUG.pdb /NODEFAULTLIB:msvcprtd.lib
RELEASE_LDFLAGS = $(LDFLAGS) /INCREMENTAL:NO /OPT:REF /OPT:ICF

/INCREMENTAL is default so you don't need it for Debug.
 
When you make a 30 second fix, you don't want to have to wait 10 minutes to verify that it worked.

Ditto. I really prefer python modding (I can say that now that I have done both :) because if I make a simple mistake in the code, I do not even have to leave the game to fix it. Just edit the python, the game automatically reloads it, and I can retry the failed situation again. The turnaround time is zero. A turnaround time of 10 minutes for a full recompile, or even 2 minutes for one module recompile and relink, *greatly* decreases my productivity.
 
Top Bottom