How much time does it takes you to compile Irrlicht?

[elander]

I have compiled it with with CodeBlocks in 4 minutes and 30s with a P4 3Ghz and 2Gb ddr ram.

The biggest ofenders to compilation time are the mesh loaders.

Can we get this value even lower than this?

Heres one sugestion Ogre and Panda3d use its own mesh format and any other format is converted to their native xml or text format. When meshes are read for the first in Panda (not sure about this) they are checked to see if a binary mirror of the same mesh was compiled and if that binary mesh has an internal version compatible with the current engine. If not the mesh is recompiled to binary automaticaly.

Now heres the idea instead of wasting time with a custom format why not using Collada and an algorithm to compile Collada to a binary format that engine version dependent for maximum efficiency? I think this is the best path and the one that most successful engines are taking. It also reduce Irrlicht size and compile time a lot.

[afecelis]

1 min 15 secs with MSVC toolkit as compiler, 4 min 15 secs with GCC. Both with C:B as IDE. So I guess you're compiling with GCC. My rig is an AthlonXP 3200+ with 1 gb of Ram.

[hybrid]

I hope this posting is meant to be a joke in some way. Are you really concerned about compilation time? If you are working with a rendering library all you should be concerned about is frames per second. And typical compiler optimizations can easily double compilation time to bring maybe 10% higher frame rate. And I guess that everybody else on the forum would want to use this. So to bring it to a simple rule of thumb: Everything that can be done during complation should be done there.

[afecelis]

Hybrid's right. The more you get on compile the better. Besides, even 5 minutes is not much to wait. Some user reported he was getting Irrlicht in 45 minutes and he was happy if he could bring it down to 30 minutes Of course his was a hard drive problem or hardware problem. Anyway, Irrlicht has always been fast to compile if you weigh what you get.

you'd die compiling Torque!

[Halan]

that was me who needed 45 min on a crappy laptop

not with my atholon fx 4200 i need only 2 min or so even with gcc

[afecelis]

hehehe, thanks for your testimony Halan!

[hybrid]

Any by disabling the debug mode (which came in accidentially, also for the Linux Makefile) it should become much faster again for Dev-C++. For codeblocks you could disable optimzations which should make it much faster again (but only compiling, not running - here it depends on your own choice what's better )

[vitek]

I admit that reducing compile time is not really that important given that you shouldn't be recompiling irrlicht all that often, and 5 minutes isn't really that long. But...

If you were really concerned with minimizing compile time, one way to do so would be to reduce the number of unnecessary includes. I see that some headers use includes for classes that are not really used. Most of the time a forward declaration could be used instead.

Another way would be to use precompiled headers on VC, but that would be a platform specific build optimization.

Travis

[elander]

I hope this posting is meant to be a joke in some way. Are you really concerned about compilation time?

Only for curiosity don't worry. Im quite happy with Irrlicht compilation time. This is probably the samller and faster to compile engine (with a good set of features) on the net as you may very well know.

The more you get on compile the better.

My sugestion goes beyond the compilation time issue. I will post it in another thread to make it more clear.

I didn't find any debug option activated in CodeBlocks. What i did find was -O3 and -expensive-optimizations flags set. The strange thing is that it took alomst the same time : 4min13s.

Damn i can't believe GCC is being beaten by M$.

Did you used MSVC7.1 or the new microsoft free compiler? Also did you used percompiled headers?

[hybrid]

If you were really concerned with minimizing compile time, one way to do so would be to reduce the number of unnecessary includes. I see that some headers use includes for classes that are not really used. Most of the time a forward declaration could be used instead.

There are indeed some unused headers (which I'm trying to reduce), but forward declarations should not be used instead. Read the optimization paper Niko announced on his blog recently. The compiler looses some optimization possibilites if it does not know the real size of the objects. But as said when high performance is required the compiler should get all the time it wants.

[vitek]

The compiler looses some optimization possibilites if it does not know the real size of the objects

Hmmm. Maybe you could point me to the location in the paper that indicated using forward declarations caused optimization problems.

I agree that it is sometimes necessary to include the header. In cases where the compiler needs to know the size of an object, you should be including the header. The size of the object is needed when you are accessing member data, using sizeof, allocating or deallocating instances, inheritance, composition, or by-value parameters.

You do not need a full declaration when a pointer or reference to a type is being used as a function parameter type or a return type in a function declaration. You also do not need a full declaration when a pointer or reference to a type is used as member data in a class declaration. You _do_ need the full declaration when dereferencing the pointer or reference.

Code: Select all

// B.h
#include "A.h"
// class A; // fwd decl is all that is needed

class B
{
public:
  B();
  ~B();
  void foo();
private:
  A* a;
};

// B.cpp
#include "B.h"
#include "A.h"

B::B()
{
  a = new A;
}

B::~B()
{
  delete a;
}

void B::foo()
{
  a->foo();
}

Code: Select all

// Z.h
#include "X.h"
// class X; // fwd decl is all that is needed

class Y
{
public:
  virtual void foo(X* x) = 0;
  virtual void foo(X& x) = 0;
};

// Z.h
#include "Y.h"
class Z : public Y
{
public:
  virtual void foo(X* x);
  virtual void foo(X& x);
};

// Z.cpp
#include "Z.h"
#include "X.h"
void Z::foo(X* x)
{
  // use x
}
void Z::foo(X& x)
{
  // use x
}

In the above case, the first include for X.h is unnecessary. A forward declaration would be just as good, and is in fact better for compile time when X.h requires a lot of preprocessing or parsing. When some other class inherits from Y and implements foo(), X.h would need to be included (as shown in class Z's definition).

There are many places in Irrlicht where forward declarations are used, and used correctly. Unfortunately there are many interface class headers that unnecessarily include other headers.

[vitek]

The other advantage of properly avoiding includes is that fewer modules will need to be recompiled if a single header changes. As an example, a change to ITexture.h requires that nearly every file in the irrlicht library be recompiled. This is because SMaterial.h includes ITexture.h.

Making the required change in SMaterial.h and adding the necessary ITexture.h include in other places would have a small but noticeable effect when recompiling Irrlicht.

If I had a huge project that included SMaterial.h in many source files but never actually used the texture pointers, my compile times would be drastically affected by a change to ITexture.h.

[hybrid]

It's chapter 6.8, member pointers. It's really an astonishing document
I know the places where includes are required (and also the compiler usually tells us if something's forgotten). But esp. interface includes should contain all necessary headers because they either require them anyway due to inline implementations and because otherwise the enduser would be required to include additional headers anyway, at least in the majority of cases.

[zenaku]

The only time you want fast compilation time is during development, but then you should only ever be recompiling what has changed. There is no need to rebuild everything to change one file. Using visual studio incremental linking and edit & continue debugging you can compile and run each line as you type. At that point does it matter how long it takes to compile? It compiles it faster than you can type it in.

I have an autogenerated .cpp file in my project that is ~80K lines of code. It takes visual studio 2003 30 sec to compile it while gcc-4.0 takes 2 minutes, which is a 4x speed difference.

Yes, gcc has been beaten by Visual Studio, at least in the speed department.

[zenaku]

There are many places in Irrlicht where forward declarations are used, and used correctly. Unfortunately there are many interface class headers that unnecessarily include other headers.

I have to disagree here. I've went through and compiled implementations of all the methods in each interface header file of irrlicht while making IrrLua. Each interface header ONLY #includes header files it needs to compile. If you exclude any of those headers it simply will not build. IMO Irrlicht's headers are pretty clean in this regard, at least for 1.0. I haven't looked at 1.1 yet. Maybe things have gotten ugly?