Оверхед для ООП

 

В связи с одной ресурсоемкой задачей возник вопрос - какой оверхед дает использование ООП по сравнению с обычным процедурным программированием. 

Кто-нибудь делал подобные тесты?

Интересует разница между:

  1. Вызов функции с параметрами
  2. Вызов функции без параметров
  3. Вызов макроса с функционалом вышеупомянутой функции
  4. Вызов функции - метода класса
  5. Вызов виртуальной функции

 

О каком оверхеде речь ?

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

Гораздо важнее овехед программерский - написание и поддержка кода, устранение ошибок...

 

Функции без параметров быстрее чем функции с параметрами.

 
Dmitry Fedoseev:

Функции без параметров быстрее чем функции с параметрами.


Само собой, все же я на ассемблере 2 года бацал )) Правда, для embedded процессоров, но С++ он и в Африке С++. Даже у функции без параметров есть пролог и эпилог, тоже отнимает время.

Самое быстрое это конечно макрос, оформленный под функцию. Жаль, в MQL нет inline functions, но макрос будет некоторой заменой

 
George Merts:

О каком оверхеде речь ?

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

Гораздо важнее овехед программерский - написание и поддержка кода, устранение ошибок...


Оверхед времени исполнения конечно, лишние килобайты нас не волнуют. Тест что ли сделать..

 

Макрос конечно будет быстрее всего. 

 
Alexey Volchanskiy:
 

Самое быстрое это конечно макрос, оформленный под функцию. Жаль, в MQL нет inline functions, но макрос будет некоторой заменой

Ринат говорил, что в МТ - работает серьезный инлайнер, и дает неплохие результаты.

 
George Merts:

Ринат говорил, что в МТ - работает серьезный инлайнер, и дает неплохие результаты.


Да есть, по личным наблюдениям в МТ4 работа инлайнера зависит от размера стека (выделяемой памяти под переменные в стеке) и количества переменных.
А в МТ5, показалось, что зависимость от размера стека убрана и оптимизатор там помощнее в целом.

 
Alexey Volchanskiy:

В связи с одной ресурсоемкой задачей возник вопрос - какой оверхед дает использование ООП по сравнению с обычным процедурным программированием. 

Кто-нибудь делал подобные тесты?

Интересует разница между:

  1. Вызов функции с параметрами
  2. Вызов функции без параметров
  3. Вызов макроса с функционалом вышеупомянутой функции
  4. Вызов функции - метода класса
  5. Вызов виртуальной функции

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

единственный нюанс - наличие хороших ОО библиотек.

"Стандартная библиотека" нарушает моё чувство прекрасного и заставляет уходить в DLL и спокойно кодить в С++


 
George Merts:

Ринат говорил, что в МТ - работает серьезный инлайнер, и дает неплохие результаты.

Да, инлайнер очень агрессивный и автоматический.

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

А вот где реальный оверхед, так это в операциях со ссылками и контроль динамических индексов. Их приходится постоянно контролировать.

 
Alexey Volchanskiy:

В связи с одной ресурсоемкой задачей возник вопрос - какой оверхед дает использование ООП по сравнению с обычным процедурным программированием.

Разумеется за красивости ООП надо платить ресурсами и большими расходами времени по отладке. ООП имеет смысл лишь как удобная обертка текста либо при минимальном использовании при инициализации среды исполнения... По сути ООП это была чисто маркетинговая штука от Микрософота для повышения расходов на рабочие часы программистов и стимулировании покупки более продвинутого оборудования. Причем сами они не дураки и весь софт пишут на Си и ассемблере.

Причина обращения: