Greetings!
I have 3 compilation passes in my game/engine: The platform layer, the game's DLL and a code generator/metaprogram.
On an i5 3570K and a 3 years old SSD both the game and code generator compile within a second!
However; the platform layer seems to take a lot longer time. Almost 3 times slower (combined with the game dll and code generator they would all take about 3 seconds)
I know 3 seconds isn't really much. I mean hey CPP and templates people wouldn't even dream of hitting this speed but still, I like to milk the performance out of things if I could.
The question is, why is the platform layer taking longer? I guess it's because we're linking against user32.lib and gdi32.lib? What happens if we load the code we need out of those dynamically? is it because of those .libs or are there other reasons? maybe something in my compiler flags?
Here's my build script:
[Code]
@echo off
pushd W:\Projects\Breakout\build
set SrcDir="..\\src\\"
set CommonCompilerFlags=-MTd -nologo -fp:fast -Gm- -GR- -EHa- -Z7 -W3 -wd4996 -wd4201 -wd4100 -wd4189 -wd4505
set CommonLinkerFlags=-incremental:no -opt:ref
REM Engine exe
cl %CommonCompilerFlags% ..\src\Win32Platform.cpp -FmWin32Platform.map /link %CommonLinkerFlags% user32.lib gdi32.lib
REM Game DLL
call %SrcDir%build_game.bat
REM Generator exe
cl %CommonCompilerFlags% ..\src\CodeGenerator.cpp
popd
[/Code]
Appreciate any advice.
Thanks!
elxenoanizd/vexe
I have 3 compilation passes in my game/engine: The platform layer, the game's DLL and a code generator/metaprogram.
On an i5 3570K and a 3 years old SSD both the game and code generator compile within a second!
However; the platform layer seems to take a lot longer time. Almost 3 times slower (combined with the game dll and code generator they would all take about 3 seconds)
I know 3 seconds isn't really much. I mean hey CPP and templates people wouldn't even dream of hitting this speed but still, I like to milk the performance out of things if I could.
The question is, why is the platform layer taking longer? I guess it's because we're linking against user32.lib and gdi32.lib? What happens if we load the code we need out of those dynamically? is it because of those .libs or are there other reasons? maybe something in my compiler flags?
Here's my build script:
[Code]
@echo off
pushd W:\Projects\Breakout\build
set SrcDir="..\\src\\"
set CommonCompilerFlags=-MTd -nologo -fp:fast -Gm- -GR- -EHa- -Z7 -W3 -wd4996 -wd4201 -wd4100 -wd4189 -wd4505
set CommonLinkerFlags=-incremental:no -opt:ref
REM Engine exe
cl %CommonCompilerFlags% ..\src\Win32Platform.cpp -FmWin32Platform.map /link %CommonLinkerFlags% user32.lib gdi32.lib
REM Game DLL
call %SrcDir%build_game.bat
REM Generator exe
cl %CommonCompilerFlags% ..\src\CodeGenerator.cpp
popd
[/Code]
Appreciate any advice.
Thanks!
elxenoanizd/vexe
Edited by vexe
on
Usually that's because of windows.h include. It includes so much crap that it is no wonder C preprocessor/parser needs to spend some time of it.
If you want to see how much code it generates, then create empty foo.c file, put #include <windows.h> in it, and run "cl /P foo.c". Then check how big is foo.i file.
One thing you can do is put "#define WIN32_LEAN_AND_MEAN" before windows.h include. It should significantly reduce size of generate code by not including rarely used Windows API declarations. Most likely you don't need them.
There is no easy way around that. If you want to spend some time fixing this, you could create your own "miniwin.h" include where you would copy&paste only needed defines/typedefs/functions from real windows.h&friends.
Linking one or two libraries usually doesn't hit performance much.
If you want to see how much code it generates, then create empty foo.c file, put #include <windows.h> in it, and run "cl /P foo.c". Then check how big is foo.i file.
One thing you can do is put "#define WIN32_LEAN_AND_MEAN" before windows.h include. It should significantly reduce size of generate code by not including rarely used Windows API declarations. Most likely you don't need them.
There is no easy way around that. If you want to spend some time fixing this, you could create your own "miniwin.h" include where you would copy&paste only needed defines/typedefs/functions from real windows.h&friends.
Linking one or two libraries usually doesn't hit performance much.
Edited by Mārtiņš Možeiko
on
Thanks I'll try those. Note I don't actually include Windows.h
The only stuff I include that I didn't write are:
#include <Windowsx.h> // for GET_X_PARAM. I'll probably remove this later
#include <dsound.h>
I tried to see if any of those headers include Windows.h themselves but didn't see it.
The only stuff I include that I didn't write are:
#include <Windowsx.h> // for GET_X_PARAM. I'll probably remove this later
#include <dsound.h>
I tried to see if any of those headers include Windows.h themselves but didn't see it.
Edited by vexe
on
WIN32_LEAN_AND_MEAN reduced Foo.c size from 3MB to 1.23MB. However adding it to my code I now get direct sound errors. http://i.imgur.com/S2iWr2K.png :( I guess I have to load these functions dynamically or something.
Loading functions dynamically won't help compile speed at all. If you cannot include headers you cannot compile. If you include headers (windows.h), then everything is already slow, so changing something else at runtime won't gain anything.
It appears dsound.h wants WAVEFORMATEX type. It is usually available from mmsystem.h, I guess it get's excluded when WIN32_LEAN_AND_MEAN is defined. So change includes to this (you'll need this header anyway if you'll want to use timeBeginPeriod function):
It appears dsound.h wants WAVEFORMATEX type. It is usually available from mmsystem.h, I guess it get's excluded when WIN32_LEAN_AND_MEAN is defined. So change includes to this (you'll need this header anyway if you'll want to use timeBeginPeriod function):
1 2 3 4 | #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <mmsystem.h> #include <dsound.h> |