Возможно ли снижение производительности при использовании расширенного варианта Pimpl?

Представь себе это.

Я хочу создать классы, которые не раскрывают ничего из их базовой реализации. Даже не это, что есть указатель на реализацию.

Я бы сделал это с глобальным пулом объектов.

Что-то вроде этого.

Класс Test, реализованный в классе TestImpl.

Когда Test создается, он создает TestImpl для себя в глобальном пуле объектов.

Пул объектов в основном будет картой для каждого типа. Ключом будет адрес памяти экземпляра Test, а значением будет соответствующий TestImpl. Поэтому каждый раз, когда вызывается функция-член в Test, она сначала получает соответствующий TestImpl из пула объектов, используя указатель this в качестве ключа.

Этот вид пула объектов, конечно, должен быть синхронизирован, нужны блокировки.

Как вы думаете, насколько большой удар по производительности может создать такое решение?

1 ответ

Решение

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();
}
Другие вопросы по тегам