Ogre compilation sizes/time

Started by
6 comments, last by Gorg 17 years, 9 months ago
I tried posting this question on Ogre's own forums, but they don't seem very active, and nobody posted any reply, so I figured I would try on my home territory, so to speak [smile] Anyway, I am re-starting game development with Ogre, after a not entirely successful sojourn to write my own engine. I am developing on a 3-year old 867Mhz PowerBook, running OS X 10.4, 512MB Ram, so not a speed-demon, but not typically to slow to work with. Ogre is just as easy to get up and running as ever, but compilation has been a pain in the ass. Even an empty soucre file that includes "Ogre.h" suddenly produces 4MB+ object files, with similarly bloated compilation times. In some areas, I can reduce size/time by only including a few Ogre headers, typically various Math headers, but if I include "OgreRoot.h" or any of the scenegraph headers it ballons again. I tried setting up "Ogre.h" as a precompiled header, but as XCode only supports precompiled prefix headers, this just meant that every file grew exponentially, and overall compilation time actually increased! Linking against the release build didn't help any either, although it didn't hurt (and the release lib is only ~10MB as opposed to ~120MB for debug). So I was wondering if anyone had any suggestions for coping with this (other than buying a faster computer, which I am not currently in a position to do)?

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement
It appears you haven't gotten much of a response here either... The Ogre forums are in no way "not very active". Perhaps your post there was... Not so up to par. Very shady (not saying it is, just noting a fact) posts tend to get ignored, and if it's a question that's been answered more than 3 times, it will get ignored.

As far as your problem:
I'm no expert. But I wonder- what's wrong with the sizes of compilation time? Are you using the flat source, or the SDK? It's not a 5 file deal here, so of course it will take some time... I mean, with version 1.2 SDK, the first compile for a demo takes about 2 minutes on my machine. What kind of compile times are you getting? So far the only option I can see for faster compile times, is a new computer. Or expensive third party software.
Sorry, I didn't noticed anyone had replied here lately ;)
And I appologise if I was a bit harsh on the OGRE forums, I guess I was a little frustrated when I posted here.

Now I have a new computer (as of last week), and the compilation times are no longer much of a problem, adn I am getting compilation times a little faster than your 2 minutes, (my 3-year old machine was really struggling, 12 minutes for each of those demos).

The compilation sizes are still bugging me though; why does each object file that includes "Ogre.h" imediately grow to 4+ Megabytes, even theough it does not instantiate any Ogre classes???

ATM, I am having another issue, it seems their is no packed build of DevIL for Mac-Intel systems, and I have been unable to get it to build from source, so I am unable to run Ogre based applications natively. Hopefully someone else (maybe the ogre team) will figure this out soon.

Thanks for your reply anyway,

Tristam

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Unfortunately, Ogre is using a huge amount of disk space if you compile it from source - regardless of the platform. Last time I used Ogre (v.1.1 or something), it required more than 1.5GiB hard disk space for object files and libs.
Demos and apps built on top of Ogre tend to need some 20MiB (debug builds) or 10MiB (release builds) for the executable, the libs and the plugins.
Quote:Original post by darookie
Unfortunately, Ogre is using a huge amount of disk space if you compile it from source - regardless of the platform. Last time I used Ogre (v.1.1 or something), it required more than 1.5GiB hard disk space for object files and libs.
Demos and apps built on top of Ogre tend to need some 20MiB (debug builds) or 10MiB (release builds) for the executable, the libs and the plugins.


The debug lib by itself is 125Megs on the Mac ;)
Luckily the release lib is only ~12Megs, but I have worked with the source a little, and I really don't see why it is so huge.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

That's because Ogre.h includes every header file used by Ogre.

This means that every thing that can be compiled from those header (like inline functions, instantiated templates, etc..) will get created in every compilation unit that included Ogre.h in some way.

For example, on some compilers if you have std::vector<type>, the compiler will generate every function from std::vector even if they are not used. This increases the code by quite a bit.

In release mode, the compiler and/or linker is more clever and will remove unused function references or not generate them at all, so this will give a normal size exe or dll.
Quote:Original post by Gorg
That's because Ogre.h includes every header file used by Ogre.
This means that every thing that can be compiled from those header (like inline functions, instantiated templates, etc..) will get created in every compilation unit that included Ogre.h in some way.

I figured that, but it still seems excessive. The whole of IrrLicht is nowhere near that large on the same compiler/machine, and while I know OGRE has more features and so on, it still seems big.
Quote:For example, on some compilers if you have std::vector<type>, the compiler will generate every function from std::vector even if they are not used. This increases the code by quite a bit.

I doubt this is the case on GCC 4, but one never knows.
Quote:In release mode, the compiler and/or linker is more clever and will remove unused function references or not generate them at all, so this will give a normal size exe or dll.

Which is still over 10Megs for the release dylib. And then each .cpp using Ogre headers balloons up to ~1Meg, until I turn on 'dead code stripping' which strips out to fairly compilation normal sizes (the only problem is, dead code stripping doesn't play nicely with Ogre's dylib at the moment).

Anyway, now that I have the new computer its not such a problem, thanks for the help.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

GCC will catch errors in template code even if you are not using the function, which would tell me that they are compiling all the functions.

Of course that does not mean the code will actually be emitted, and I haven't checked.

On the other end, Visual Studio will allow the error. I prefer the GCC behavior.

This topic is closed to new replies.

Advertisement