Оптимизация поиска виртуальных таблиц

С кодом, как показано ниже, может ли компилятор сказать, что a на самом деле является примером B и оптимизировать поиск виртуальной таблицы?

#include <iostream>

class A
{
public:
virtual void f()
{
std::cout << "A::f()" << std::endl;
}
};

class B : public A
{
public:
void f()
{
std::cout << "B::f()" << std::endl;
}
};

int main()
{
B b;
A* a = &b;
a->f();

return 0;
}

Дополнительный вопрос после ответов Jonthan Seng и reima: в случае использования gcc, нужно ли будет использовать какие-либо флаги, чтобы заставить его оптимизировать поиск в vtable?

5

Решение

лязг может легко сделать эту оптимизацию и даже встроить вызов функции. Это видно из сгенерированной сборки:

Dump of assembler code for function main():
0x0000000000400500 <+0>: push   %rbp
0x0000000000400501 <+1>: mov    %rsp,%rbp
0x0000000000400504 <+4>: mov    $0x40060c,%edi
0x0000000000400509 <+9>: xor    %al,%al
0x000000000040050b <+11>:  callq  0x4003f0 <printf@plt>
0x0000000000400510 <+16>:  xor    %eax,%eax
0x0000000000400512 <+18>:  pop    %rbp
0x0000000000400513 <+19>:  retq

Я взял на себя смелость замены std::cout << … эквивалентными звонками printf, так как это значительно уменьшает беспорядок в разборке.

GCC 4.6 также может сделать вывод, что поиск vtable не требуется, но не встроен:

Dump of assembler code for function main():
0x0000000000400560 <+0>: sub    $0x18,%rsp
0x0000000000400564 <+4>: mov    %rsp,%rdi
0x0000000000400567 <+7>: movq   $0x4007c0,(%rsp)
0x000000000040056f <+15>:  callq  0x400680 <B::f()>
0x0000000000400574 <+20>:  xor    %eax,%eax
0x0000000000400576 <+22>:  add    $0x18,%rsp
0x000000000040057a <+26>:  retq
5

Другие решения

Может быть, это может зависеть от умений компилятора и требований оптимизации.

Но это один звонок. Почему вы заботитесь об оптимизации этого звонка? И, если вам все равно, почему бы просто не получить правильный тип для этого одного вызова?

Первый ответ на все вопросы об оптимизации: «Зачем вам это оптимизировать?» Подготовьте отчет по инструменту повышения производительности, в котором говорится, что 50% времени подачи заявки — это одно место, и на вопрос дан ответ. «О, но его неэффективность», наиболее распространенный ответ, приводит к не поддерживаемому коду, который редко оптимизирует код, который на самом деле неэффективен.

-2

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector