угу на вебе    и в 10 раз быстрее ,  там девация 0 вас не это смущает, мне кажеться что 
там интерпритатор , который имулирует компиляцию 
Я измерил открыл Code Block c gcc хотя надо бы в студии но ее счас нетy,


проделал раз 10 максимум что удалось получить это 192,0 vs 158.0

на 11раз получил 

Times for:
virtual function = 172.0,  plain function = 182.0
virtual function = 158.0,  plain function = 147.0
virtual function = 160.0,  plain function = 150.0

sum = 1863248640

Process returned 0 (0x0)   execution time : 0.995 s
Press any key to continue.


потом проверил еще пару раз и вот 
Times for:
virtual function = 177.0,  plain function = 161.0
virtual function = 189.0,  plain function = 205.0
virtual function = 170.0,  plain function = 162.0

sum = 1863248640

Process returned 0 (0x0)   execution time : 1.091 s
Press any key to continue

т,е мы видим что разницы нет , 


mes ,
сказал  ответили что ставять inline   это раз и пишут на С это два ,
вызов VF в сpp это сишный вызов поинтера на функцию ,  хотя там где critical necessary компайлеру лучше не доверяться а делать самому, классический пример "умная пуля" , 

Я говорил про бизнес  обьекты, с "тупо везде" перегнул,  у вас скорее конвертер который вообще должен быть static ,
IMHO,





Это сообщение отредактировал(а) sergioK1 - 14.7.2013, 21:27

не знаю, где в креаторе наболтать оптимизацию, но по дефолту на нетбуке цифры такие

Times for:
virtual function = 300.0,  plain function = 50.0
virtual function = 300.0,  plain function = 50.0
virtual function = 300.0,  plain function = 50.0


sergioK1, релиз запусти, а не дебаг.

Да в дебаге без разницы в релизе в 4раза
И не помогает оптимизация , Страустроп пишет что разница  не значительная  ,
он не знает С++ ??? 

sergioK1, что такое вызвать функцию? Это делает инструкция call <address>. Она есть практически в любом процессоре. Но в некоторых РИСКах ее может не быть, тогда это делается вручную: адрес возврата записывается в стек, указатель стека смещается на размер адреса возврата, происходит загрузка в указатель команд адреса процедуры.
Когда имеется вызов виртуальной функции, то тут все сложнее: сохранить адрес возврата, сместить указатель вершины стека, загрузить адрес процедуры в указатель команд, загрузить адрес таблицы виртуальных функций, добавить смещение, загрузить адрес функции.
А теперь вспомним, что на С++ пишут в основном не под микроконтроллеры, а под "большие" машины архитектуры x86 (или x86_64). Чем она отличается? А тем, что кроме всего вышеперечисленного есть кэш и многостадийный конвеер. Таким образом, если производится одновременная работа с большим количеством данных, то кэш начинает тормозить весь процесс - происходят постоянно промахи и приходится заменять одни данные другими. А вот конвеер спотыкается на переходах. И, есть у меня подозрение, что их предсказатель далеко не всегда успешно справляется при вызове виртуальных функций, так как в момент принятия решения адрес перехода может фактически отсутствовать в доступности процессора. А если предсказание перехода завершилось неудачей, то после выявления этого весь конвеер будет сброшен и процессор "потеряет" более десятка тактов...

Когда разработчик проектирует класс, он предусматривает, что пользователь может переопределить, а что в принципе не должен. Причем, опыт показывает, что 90% методов классов в переопределении не нуждаются.

Главная философия языка "не делать то, о чем не просили".

Если ты хочешь переопределить у стека метод reserve (нахрена?), то сделай это путем агрегации (сделай свой стек, который содержит в себе стандартный). Все равно, все члены класса приватные и ты из потомка к ним доступа не получишь.
Если ты хочешь изменить аллокатор, то может стоит именно это и сделать? Посмотри на второй параметр шаблона.

И не забывай, что все стандартные контейнеры самодостаточны. Их не требуется как-то "дореализовывать".

Кстати, то что какие-то части стандартной библиотеки писали "студенты" не означает, что это студенты проектировали. В комитете по стандартизации сидят довольно серьезные люди.

volatile 
NoviceF

Это обман трудящихся     разбейте все по отдельным файлам , 
у меня даже 1% разницы нет , 

Это сообщение отредактировал(а) sergioK1 - 16.7.2013, 20:38

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

Я считаю, что делать все функции виртуальными - это лишнее.
Но думаю не помешал бы блок вроде public virtual:

sergioK1,  тут уже говорилось что код нужно проверять на максимальной оптимизации на скорость.
То что у вас скорость зависит от "разбиения на файлы", говорит лишь о том что у вас не включен элементаный
link-time code generation.

Да и потом изучайте мат-часть.
То что вирт. функция будет медленней - даже спорить смешно.

где его включать? 

вопрос неправильно  ставите(это масчеи матчасти   )  не virtual vs regular , 
а static call vs dynamic call , т,е вопрос можно ли оптимизировать что-бы был статик?
в чистом С это можно(судя по тестам), почему в С++ нет ? 

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

В случае не вирт. функции, никакого вычисления в ран-тайме НЕ нужно.
Все известно на момент компиляции. И компилятор просто подставляет жесткий адрес функции.

если известен тип, с++ позволяет оптимизировать виртуальный вызов..

Если известен тип, тогда смысла в виртуальной функции нет.

Добавлено через 2 минуты и 37 секунд
Естествеено, если взять пример с одним типом, как код выше, ясно что там другого просто не будет.
В реальных программах (сколько нибудь сложных) - так не бывает.

зато есть смысл в оптимизации такого вызова 



зато бывает в тестах, что мешает некоторым (как например тс)  адекватно оценить затраты на виртуальность..

Добавлено через 2 минуты и 23 секунды

и все ж бывает..

Это сообщение отредактировал(а) mes - 29.7.2013, 16:04

Аналогично, можно еще очень сильно настаивать на том, что скорость умножения, вообще не имеет значения в программировании
основываясь на том что высосанный из пальца тестовый код  выполняется моментально:


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

Добавлено через 3 минуты и 54 секунды

Так - же и с вашими оптимизациями вирт.функций.
Там где их компилятор сможет оптимизировать, там вообще не нужно виртализация.
И лучше рассмотеть использвание шаблонов!

Там гораздо надежнее получите высокооптимизированный код

как по мне тут соленное с влажным сравнивается.. 

Вот здесь люди тоже сравнивают :
Сравнение влажного с соленым
есть и еще с десяток тысяч линков, найдете без труда в гугле...