У самого Java компилятора маневров для оптимизации кода вызова виртуальных методов не так и много - инструкции invokevirtual и invokeinterface. Использование invokeinterface может сказаться на времени вызова метода не самым лучшим образом. Остальные оптимизации уже за JIT-ом.

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

Когда инстанцируется шаблонный класс, в котором есть виртаульная функция, она будет инстанцирована всегда, даже если в коде она не используется (актуально для старых версий gcc и MSVС компилятора, с новыми не проверял), в отличие от всех других функций шаблонного класса. Что может приводить к невозможности использовать шаблонный класс там, где ограничений для его применения на самом деле нет. Например, невозможно создать экземпляр MFC контейнера CArray с типом с закрытым конструктором по умолчанию из-за виртуальной функции Serialize.

NoviceF, ну это скорее ограничения обычного класса чем шаблонного. Таблица VMT должна содержать записи всех виртуальных функций и все указатели должны указывать на реальные адреса. Представь, что я каким-нить неявным для компилятора образом образом, получу указатель на предка (к примеру COM интерфейс) и передам его за границу модуля в Dll, и оттуда вызову виртуальную функцию. Раз компилятор не может отследить, то обязан всегда все виртуальные функции помещать в исполняемый модуль и все записи помещать в VMT. 
  В случае же простой функции компилятору достаточно убедиться, что ни где нет оператора взятия адреса функции и она ни где явно не вызывается, чтобы не компилировать ее и не включать в образ. Для виртуальной функции именно неявный вызов является причиной того, что она всегда будет включаться в образ и это не зависит от версии компилятора и не может быть иначе реализовано. 

Ну и жесть  жутко надуманный пример однако

нуттак  , главное он затрагивает нужные аспекты:)

Это сообщение отредактировал(а) mes - 16.8.2013, 09:42