Interface and Implementation: The Need for Speed

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
lingwitt
Posts: 47
Joined: Mon Jun 19, 2006 9:38 am

Interface and Implementation: The Need for Speed

Post by lingwitt »

While inline functions are obviously present to speed up operation, I doubt the speed increase is that vast, or even that inlining takes place on that large of a scale.

Moreover, any advantage from placing implementation in the header files is destroyed by the long wait for the library to be built after every change in a header.

I propose that the implementation be moved completely into .cpp files.

Could I please hear opinions against this?
hybrid
Admin
Posts: 14144
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Well, inlining is an important feature in OOP since get and set methods would otherwise introduce major performance issues. And implementing container classes and basic data types purely in headers is very common. Take STL which comes in large parts in headers only.
If you'd followed the current trends in compiler development you'd have noticed that currently everything goes into compiling time. Unless you have a very bad compiler you can say that the longer the compilation takes, the better for the code. Profiling optimizations are even compiling code twice to get better performance.
And your chances are very high that if you have to change something in your header it's not just in getters or setters such that you'd have to compile everything dependent on this file again with or without header implementations.
lingwitt
Posts: 47
Joined: Mon Jun 19, 2006 9:38 am

Post by lingwitt »

Getters and Setters don't require algorithms or implementation that may change. Inlining them is probably inescapable.

Moreover, the STL is in header files because it is composed of templates, which must be defined in any module that makes use of them.

Larger implementations should be moved to compilable modules. For instance, take this in COpenGLMaterialRenderer.h:

Code: Select all

virtual void OnSetMaterial(SMaterial& material, const SMaterial& lastMaterial,
    bool resetAllRenderstates, IMaterialRendererServices* services) 
{
    if (material.MaterialType != lastMaterial.MaterialType || resetAllRenderstates)
    {
        if (Driver->hasMultiTextureExtension())
        {
            Driver->extGlActiveTextureARB(GL_TEXTURE1_ARB);
            glDisable(GL_TEXTURE_2D);
            glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);

            Driver->extGlActiveTextureARB(GL_TEXTURE0_ARB);
        }
        
        glDisable(GL_BLEND);
        glDisable(GL_ALPHA_TEST);
    }

    services->setBasicRenderStates(material, lastMaterial, resetAllRenderstates);
}
Post Reply