Блеск и нищета ООП

Новый комментарий
 

Базовый класс, несколько потомков, используется один из потомков, в зависимости от параметров установленных на запуске. Это всем известный принцип работы универсальной программы. Не важно сколько вариантов может быть (т.е. классов - потомков), подразумевается, что это дело должно работать очень быстро, так как нет никаких вызовов if или switch для изменения работы программы, только один раз при инициализации выбрали нужный класс - потомок, дальше все работает прямо и просто. 

class CBase{
   private:
   public:
      virtual void Fun(){
      
      }
};

class CClass1:CBase{
   private:
   public:
      void Fun(){
      
      }
};

CClass1 * cl;

void OnInit(){

   cl=new CClass1;

}

Однако...

Сколько может быть разных вариантов? Разумное число? 10, 20, 100? Даже при 100 вариантах switch работает быстрее ООП.

В приложении скрипт для сравнения быстродействия. Сравнивается вышеприведенное ООП и просто switch с функциями (причем вызывается две функции, от одного из вызовов функции можно легко избавиться).

void ff(int z){

      switch(z){
         case 0:
         f0();
         break;

         ...

         case 99:
         f99();
         break;

      }
     
}
Результаты (вызов f99): 

 

Файлы:
test.mq4  9 kb
 
Integer:

Сколько может быть разных вариантов? Разумное число? 10, 20, 100? Даже при 100 вариантах switch работает быстрее ООП.

Хочу немного предостеречь от чрезмерных обобщений.  Такой эффект резонно ожидать в mql, поскольку в нём используются виртуальные "псевдоуказатели" - по сути хендлы ссылающиеся на внутреннюю (скрытую) хеш-таблицу реальных адресов. Для разрешения таких указателей, требуется существенное дополнительное время, значительно превосходящее непосредственную адресацию по указателю.  Я не измерял, но скорее всего подобный же эффект "притормаживания" указателей будет обнаруживаться в dotNET-языках и других подобных реализациях.

В языках с "настоящими" указателями такого эффекта не будет, там switch будет проигрывать - тем больше, чем больше список выборов.

Так что ООП по сути ни при чём..

 
MetaDriver:

Хочу немного предостеречь от чрезмерных обобщений.  Такой эффект резонно ожидать в mql, поскольку в нём используются виртуальные "псевдоуказатели" - по сути хендлы ссылающиеся на внутреннюю (скрытую) хеш-таблицу реальных адресов. Для разрешения таких указателей, требуется существенное дополнительное время, значительно превосходящее непосредственную адресацию по указателю.  Я не измерял, но скорее всего подобный же эффект "притормаживания" указателей будет обнаруживаться в dotNET-языках и других подобных реализациях.

В языках с "настоящими" указателями такого эффекта не будет, там switch будет проигрывать - тем больше, чем больше список выборов.

Так что ООП по сути ни при чём..

Понятно, что дело лишь в самом компиляторе, следовательно, что при "правильной" компиляции время исполнения приведенных выше примеров сравняется.
 
icas:
Понятно, что дело лишь в самом компиляторе, следовательно, что при "правильной" компиляции время исполнения приведенных выше примеров сравняется.
Понятие "правильности" зависит от правил, следовательно бессодержательно. ;)
 

Сразу укажу ошибку: f функции пустышки и полностью вырезаны компилятором. То есть фактически никакого вызова функций нет. Еще я не уверен, до какого состояния функция ff выродится и не будет ли она в конце концов заинлайнена внутрь цикла for, тем самым убрав даже вызов функции.

А вот виртуальный метод вырезать нельзя - он вызывается всегда. В результате в одном случае просто крутится цикл, а в другом в цикле вызов.

В любых тестах в первую очередь надо доказать их корректность, а только потом переходить к результатам. 

 

Вот с не пустыми функциями:

 

Файлы:
test2.mq4  11 kb
 

Вот все функции уникальные, притом, вызываемые через switch, сложнее, чем метод класса.

 

Файлы:
test3.mq4  12 kb
 
Integer:

Вот все функции уникальные, притом, вызываемые через switch, сложнее, чем метод класса.

Как все запущено...

Вы что-нибудь про инлайнинг слышали? А про агрессивный инлайнинг?

Что обычно происходит с простыми телами функций и что с ними делает нормальный оптимизирующий компилятор? Сейчас ведь не 1995 год.

 
MetaDriver:

Хочу немного предостеречь от чрезмерных обобщений.  Такой эффект резонно ожидать в mql, поскольку в нём используются виртуальные "псевдоуказатели" - по сути хендлы ссылающиеся на внутреннюю (скрытую) хеш-таблицу реальных адресов. Для разрешения таких указателей, требуется существенное дополнительное время, значительно превосходящее непосредственную адресацию по указателю.  Я не измерял, но скорее всего подобный же эффект "притормаживания" указателей будет обнаруживаться в dotNET-языках и других подобных реализациях.

В языках с "настоящими" указателями такого эффекта не будет, там switch будет проигрывать - тем больше, чем больше список выборов.

Так что ООП по сути ни при чём..

Ага. Вот на До диезе:)


7550021 (switch)
2250004 (OOP)
7325029 (switch)
2050015 (OOP)
7550049 (switch)
2150005 (OOP)
7575031 (switch)
2325009 (OOP)
8025038 (switch)
2200004 (OOP)
7150027 (switch)
2050014 (OOP)
7375029 (switch)
2200005 (OOP)
7550022 (switch)
1950003 (OOP)
7100021 (switch)
2695083 (OOP)
7360033 (switch)
2200008 (OOP)
7825029 (switch)
1925010 (OOP)
7325025 (switch)
2025006 (OOP)
6850035 (switch)
2525014 (OOP)
7750027 (switch)
1975007 (OOP)
8195225 (switch)
2050004 (OOP)
6950020 (switch)
2425006 (OOP)
7275029 (switch)
2225015 (OOP)
7050037 (switch)
2200007 (OOP)
7375030 (switch)
 

 

Любой тест начинайте с доказательств, что он корректный и в нем реально замеряется то, что заявлено.

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

 
Renat:

Любой тест начинайте с доказательств, что он корректный и в нем реально замеряется то, что заявлено.

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

Зачем мне понимать механизмы компиляции? Только для того, чтобы уверовать, что плохой резлультат лучше хорошего?  Имеет значение результат. 
1234567
Новый комментарий
Причина обращения: