Alexeis, золотые слова

Гы   
Был случай - одна программа на Java была ускоренна в несколько раз простым прописыванием final ко всем методам всех классов, которые реально не были виртуальными.

С потоками ? 
Какая  java ? версия ? Желательно код сюда ,
А то  мой телепат в отпуске   
Хотя final или static   в жаве  грузиться заранее это фактически аналог inline ,






Это сообщение отредактировал(а) sergioK1 - 6.8.2013, 14:10

Это отключение виртуальности. Все остальное - это уже последствия.

  Это отключение корявой реализации чего-то вместе с виртуальностью. Сами же виртуальный вызов в С++ почти ничего не стоит. Есть правда еще один минус виртуальности. Компилятор не может выкидывать функции, которые ни где не использовались, если они виртуальные. Зато может инлайнить, если на 100% уверен, что будет вызвана именно эта функция.

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

пример показывай где огромна,  хватит  уже теорий   


Alexeis ,
это установка флага const в поинтер на функцию ,

  С этого момента по подробнее. Я где-то раньше читал, что вызов подпрограммы занимает 12 тактов процессора (x86), добавим сюда типичную операцию помещения в стек 1-2х параметров (хз сколько тактов), против дополнительных расходов по извлечению адреса расположенного по фиксированному смещению. По сути 2е операции с памятью. 1я получение адреса VMT, 2я получение адреса функции. Что же здесь такого накладного? Неужели промахи кеша процессора приводят к таким огромным потерям производительности?

Alexeis, я же написал, смотря с чем сравнивать. Если ты выполняешь какие-то внутренние вычисления и при этом активно используешь виртуальные методы, то производительности ты потеряешь значительную долю. А вот если 90% времени программа "отдыхает" (что-то делает система), то скорее всего, виртуальность вреда существенного не наносит.

а значит все таки стоят 

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

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

Это сообщение отредактировал(а) mes - 6.8.2013, 18:41

Не так страшен вызов виртуальной функции сам по себе, как то, что напрочь отбивает все возможности компилятора по оптимизации через границу этого вызова. И это касается не только инлайна, но и pointer анализа и вынесения общих подвыражений.
Пример -
Оптимизатор выкинет все тело цикла, и вернет сразу 10000000*(1+pow(a,b)). Если же функция Virtual::some будет виртуальной - он не сможет сделать ничего - цикл будет крутится 10000000 раз, и pow() вызываться каждый раз

Все это так но,
но при нормальном код ревью вы скорее всего оптимизируете алгоритм сами , по крайне мере постараетесь 
это сделать если пример будет более сложный,  компилятор не всемогущ и гарантий 100% что он оптимизирует нет, или нааборот из-за каких то других причин будет нельзя пользоваться оптимизацией .
Т,е ,  "проблемв  тормозов" остаюеться в теории, по крайне мере в основном 

В  java проверил final эффект нулевой 

Угу, но включенная по умолчанию виртуальность для всех методов будет этому сильно мешать. 


Разумеется, но 100% от него никто и не требует. Иначе не было бы инженеров по performance анализу (а они есть, и немало). Однако, ускорение программы в разы при включении оптимизации вполне рядовая вещь.


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


Я не говорил, что это проявится на любой java программе. Я говорил, что такие программы существуют.

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

Да вобщем то про недостатки всех функций  быть виртуальными ,по принципу а может пригодиться ,Я давно понял , надо было раньше об этом произнести  в слух  

Про final Я слышал пару раз в реальности ни разу не видел. 


И еше у меня сложилось ощущение в Java не все функции виртуальны , т,е компайлер "умнее" чем в С++ ,
т,е там где наследника нет нету виртуального механизма , Но поскольку документации по теме мизер, то 
остаеться только догадаваться так это или нет ,

Возможно. Та история, которую я тут упоминал, произошла более 20 лет назад, с тех пор компиляторы сильно поумнели   

Хотя в Java есть 2 вещи, одна из которых сильно мешает а вторая помогает проводить такие оптимизации.

В Java есть динамическая загрузка классов, так что не-виртуальный метод может в run-time привратится в виртуальный, что явно не способствует проведению оптимизации в compile-time   

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

Что, увы, автоматически перености большую часть оптимизатора в run-time, что отнюдь не добавляет надежности и устойчивости всей Java системе в целом