Ogre Forums

Hey guys,

I am mucking around with the Ogre 1.8.1 SDK at the moment.

At this stage a compilation of my current project takes about 12.75 seconds. I figure that the compilation time is due to the plethora of header files in Ogre in general (as my project consists of about two .h and two .cpp files - not a big project).

I have started merging header files manually into Ogre.h to see how fast I can get my project compiling.

I have merged about 10 files so far and have managed to knock almost half a second off compilation, so I am pretty keen to see how far I can take it

I have looked all over the net but can't find any utilities that will do this 'auto-magically'. The fastest method I have worked out so far is using Notepad++, as you can do a find and replace in a whole stack of files at once.

Still lengthy and tedious though, due to the way that Ogre headers get referenced all over the place.

If I can make a sub 6 second compilation time, it would be absolutely awesome.

I'll let you know how it goes

Aren't you doing something similar to the unity build?

are you using precompiled headers?
http://www.ogre3d.org/tikiwiki/tiki-ind ... ed+headers

Klaim wrote:Aren't you doing something similar to the unity build?

Unity build? Never used it.

frostbyte wrote:are you using precompiled headers?
http://www.ogre3d.org/tikiwiki/tiki-ind ... ed+headers

Wow, this looks like exactly what I need!

Glad I posted here, this will save a years worth of work, LOL

lonewolff wrote:

Klaim wrote:Aren't you doing something similar to the unity build?

Unity build? Never used it.

A unity build of ogremain dropped my compile time from 9min to 45sec. I like unity builds.

What is a Unity build?

https://cheind.wordpress.com/2009/12/10 ... ty-builds/
http://buffered.io/posts/the-magic-of-unity-builds/

Ogre has a CMake switch to enable that build option.

You could have googled it

Here is one explaination but there is a lot of articles about it: http://buffered.io/posts/the-magic-of-unity-builds/

Basically, put all your source code into one file compiles extremely fast IFF you manage to not have name collisions.
But it's useful only to get fast complete build, it totally kills incremental builds so it's suited for users of a big library or for when you need to change header code in that library which is used in all cpps.
It's less useful while developing the library.

Ogre's CMake scripts expose an option to compile Ogre with a Unity Build setup which will gather all project's code into one or more cpp files (I got 4 cpps, is it one by processing unit by default?)

So yeah it helps a lot with full builds.

Klaim wrote:You could have googled it

I could have, but would I have got the context correct? I initially thought it had something to do with an Ogre SDK for Unity 3D or something

"c++ unity build" works, but not "unity build" indeed.

initially thought it had something to do with an Ogre SDK for Unity 3D or something

it happens to me from time to time when i wonder "what does XXXXX have to do with unity3d??"( when it realy doesn't )
guess they got the branding right....

frostbyte wrote:

initially thought it had something to do with an Ogre SDK for Unity 3D or something

it happens to me from time to time when i wonder "what does XXXXX have to do with unity3d??"( when it realy doesn't )
guess they got the branding right....

Hehe! That's the one Unity gets the traffic either way

Brief description of Unity builds.
In a unity build you make a single base cpp that includes every other cpp. Effectively all cpp files are merged into a single massive one, that then is compiled as normal.
Each cpp in a standard build is treated as a stand alone entity. Any headers (even precompiled headers) need to be reloaded for each cpp that is built. By merging all the cpps together, headers are only loaded once.
To speed things up further, make one base cpp for each cpu core. Ogre's unity build option default to 50 ogre cpps to each unity base cpp, resulting in around 4 unity files. These can be built in parallel on a quad core system. I change it to 35 or so, which works well on my hex core cpu.

The downside is that you don't have the incremental building where changing one cpp only needs a small compile and a link with all the other temp obj files. Instead a small change to one cpp will cause everything to be rebuilt. Then again, the rebuild is so fast that may not matter.