CODEWITHSUNDEEP
c++pimpl-idiom
NFRCR
NFRCR

Reputation: 5570

Possible performance hit when using an advanced variation of Pimpl?

Imagine this.

I want to create classes that do not expose anything of their underlying implementation. Not even this that there is a pointer to the implementation.

I would do this with a global object pool.

Something like this.

A class Test that is implemented in the class TestImpl.

When Test is constructed it creates a TestImpl for itself in the global object pool.

The object pool would basically be a map for each type. The key would be the memory address of a Test instance and the value would be the corresponding TestImpl. So each time a member function on Test is called, it first gets the corresponding TestImpl from the object pool, using the this pointer as the key.

This kind of object pool must of course be synchronized, locks are needed.

What do you think how big of a performance hit such a solution would create?

Upvotes: 0

Views: 147

Answers (1)

bobah
bobah

Reputation: 18864

ifc.h

struct ifc {
    virtual ~ifc() {}
    virtual void api() = 0;

    static ifc* create();
};

impl.cc

#include "ifc.h"

struct impl: ifc {
    virtual void api() override;
}

void impl::api() {
    // code here
}

ifc* ifc::create() {
    // or use shared pointer / untrusive pointer and return object back to a pool
    // if dynamic memory allocation is not desired (but rather just keep it simple  
    // and plug something like TCMalloc first (which does low level pooling)
    // and see if it gets better)
    return new impl();
}

Upvotes: 2

Related Questions