Штраф за производительность при работе с интерфейсами на C++?

Существует небольшой штраф за вызов виртуальной функции по сравнению с обычным вызовом. Вы вряд ли заметите разницу, если не будете делать сотни тысяч вызовов в секунду, и за добавленную ясность кода часто стоит заплатить цену.

Использование абстрактных базовых классов в C++ обычно требует использования таблицы виртуальных функций, все вызовы интерфейса будут просматриваться через эту таблицу. Стоимость крошечная по сравнению с необработанным вызовом функции, поэтому убедитесь, что вам нужно действовать быстрее, прежде чем беспокоиться об этом.

Единственное главное отличие, о котором я знаю, заключается в том, что, поскольку вы не используете конкретный класс, встраивание (намного?) Сложнее.

Краткий ответ: Нет.

Длинный ответ: На скорость влияет не базовый класс или количество предков в иерархии класса. Единственное, это стоимость вызова метода.

Вызов не виртуального метода имеет стоимость (но может быть встроен)
. Вызов виртуального метода имеет немного более высокую стоимость, поскольку вам нужно найти метод, который нужно вызвать, прежде чем вы его вызовете (но это простой поиск в таблице нет a search). Поскольку все методы интерфейса являются виртуальными по определению, это требует дополнительных затрат.

Если вы не пишете какое-нибудь приложение, чувствительное к гиперскорости, это не должно быть проблемой. Дополнительная ясность, которую вы получите от использования интерфейса, обычно компенсирует любое воспринимаемое снижение скорости.

Единственное, о чем я могу думать, это то, что виртуальные методы вызываются немного медленнее, чем невиртуальные методы, потому что вызов должен проходить через таблица виртуальных методов.

Однако это плохая причина испортить свой дизайн. Если вам нужна более высокая производительность, используйте более быстрый сервер.

Когда вы вызываете виртуальную функцию (скажем, через интерфейс), программа должна выполнить поиск функции в таблице, чтобы увидеть, какую функцию вызывать для этого объекта. Это дает небольшой штраф по сравнению с прямым вызовом функции.

Кроме того, когда вы используете виртуальную функцию, компилятор не может встроить вызов функции. Следовательно, использование виртуальной функции для некоторых небольших функций может быть штрафом. Как правило, это самый большой «хит» производительности, который вы, вероятно, увидите. Это действительно проблема, только если функция небольшая и вызывается много раз, скажем, из цикла.

Что касается любого класса, содержащего виртуальную функцию, используется vtable. Очевидно, что вызов метода через механизм диспетчеризации, такой как vtable, происходит медленнее, чем прямой вызов, но в большинстве случаев вы можете жить с этим.

Да, но, насколько мне известно, ничего примечательного. Падение производительности происходит из-за «косвенности» при каждом вызове метода.

Однако это действительно зависит от используемого вами компилятора, поскольку некоторые компиляторы не могут встроить вызовы методов в классы, унаследованные от абстрактного базового класса.

Если вы хотите быть уверенным, вам следует запустить свои собственные тесты.

Следует отметить, что стоимость вызова виртуальной функции может варьироваться от одной платформы к другой. На консолях они могут быть более заметными, так как обычно вызов vtable означает промах в кеше и может нарушить предсказание переходов.

Функции, вызываемые с помощью виртуальной диспетчеризации, не встроены

Есть один вид наказания для виртуальных функций, о котором легко забыть: виртуальные вызовы не встроены в (обычную) ситуацию, когда тип объекта не известен во время компиляции. Если ваша функция мала и подходит для встраивания, это наказание может быть очень значительным, поскольку вы не только добавляете накладные расходы на вызов, но компилятор также ограничен в том, как он может оптимизировать вызывающую функцию (он должен предполагать, что виртуальная функция может изменили некоторые регистры или ячейки памяти, он не может передавать постоянные значения между вызывающим и вызываемым).

Стоимость виртуального звонка зависит от платформы

Что касается штрафа за накладные расходы на вызов по сравнению с обычным вызовом функции, ответ зависит от вашей целевой платформы. Если вы нацеливаетесь на ПК с процессором x86 / x64, штраф за вызов виртуальной функции очень мал, поскольку современный процессор x86 / x64 может выполнять предсказание ветвления при косвенных вызовах. Однако, если вы нацеливаетесь на PowerPC или другую платформу RISC, штраф за виртуальный вызов может быть весьма значительным, потому что косвенные вызовы никогда не прогнозируются на некоторых платформах (см. Рекомендации по кроссплатформенной разработке для ПК / Xbox 360).

Я не думаю, что сравнение стоимости проводится между вызовом виртуальной функции и прямым вызовом функции. Если вы думаете об использовании абстрактного базового класса (интерфейса), тогда у вас есть ситуация, когда вы хотите выполнить одно из нескольких действий на основе динамического типа объекта. Вы должны как-то сделать этот выбор. Один из вариантов - использовать виртуальные функции. Другой - переключение типа объекта либо через RTTI (потенциально дорого), либо добавление метода type () к базовому классу (потенциально увеличивающее использование памяти каждым объектом). Таким образом, стоимость вызова виртуальной функции следует сравнивать со стоимостью альтернативы, а не со стоимостью бездействия.

Другая альтернатива, которая применима в некоторых случаях, - это время компиляции. полиморфизм с шаблонами. Это полезно, например, когда вы хотите сделать выбор реализации в начале программы, и затем используйте его на время казни. Пример с полиморфизм времени выполнения

class AbstractAlgo
{
    virtual int func();
};

class Algo1 : public AbstractAlgo
{
    virtual int func();
};

class Algo2 : public AbstractAlgo
{
    virtual int func();
};

void compute(AbstractAlgo* algo)
{
      // Use algo many times, paying virtual function cost each time

}   

int main()
{
    int which;
     AbstractAlgo* algo;

    // read which from config file
    if (which == 1)
       algo = new Algo1();
    else
       algo = new Algo2();
    compute(algo);
}

То же самое с использованием полиморфизма времени компиляции

class Algo1
{
    int func();
};

class Algo2
{
    int func();
};


template<class ALGO>  void compute()
{
    ALGO algo;
      // Use algo many times.  No virtual function cost, and func() may be inlined.
}   

int main()
{
    int which;
    // read which from config file
    if (which == 1)
       compute<Algo1>();
    else
       compute<Algo2>();
}

Да, есть пенальти. Что-то, что может улучшить производительность вашей платформы, - это использовать неабстрактный класс без виртуальных функций. Затем используйте указатель функции-члена на свою невиртуальную функцию.

Большинство людей отмечает штраф времени выполнения, и это правильно.

Однако по моему опыту работы над крупными проектами, преимущества четких интерфейсов и правильной инкапсуляции быстро компенсируют выигрыш в скорости. Модульный код можно поменять местами на улучшенную реализацию, так что в итоге получится большой выигрыш.

Ваш опыт может отличаться, и он явно зависит от приложения, которое вы разрабатываете.

Обратите внимание, что множественное наследование приводит к раздуванию экземпляра объекта несколькими указателями vtable. В G ++ на x86, если у вашего класса есть виртуальный метод и нет базового класса, у вас есть один указатель на vtable. Если у вас есть один базовый класс с виртуальными методами, у вас все еще есть один указатель на vtable. Если у вас есть два базовых класса с виртуальными методами, у вас есть указатели два vtable в каждом случае.

Таким образом, при множественном наследовании (что и является реализацией интерфейсов в C++) вы платите базовым классам, умноженным на размер указателя в размере экземпляра объекта. Увеличение объема памяти может косвенно сказаться на производительности.

Я знаю, что это необычная точка зрения, но даже упоминание этой проблемы заставляет меня подозревать, что вы слишком много думаете о структуре классов. Я видел много систем, в которых было слишком много «уровней абстракции», и одно это делало их склонными к серьезным проблемам с производительностью, не из-за стоимости вызовов методов, а из-за тенденции делать ненужные вызовы. Если это происходит на нескольких уровнях, это убийца. взглянуть