O esplendor e a pobreza da OLP

Novo comentário
 

Classe base, vários descendentes, um dos descendentes é utilizado, dependendo dos parâmetros definidos no arranque. Este é um princípio bem conhecido do funcionamento universal do programa. Não importa quantas variantes possam existir (isto é, classes descendentes), este caso é suposto funcionar muito rapidamente porque não há se e mudar as chamadas para alterar a forma como o programa funciona, apenas quando a classe descendente requerida é seleccionada durante a inicialização e depois tudo funciona de forma simples e directa.

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

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

CClass1 * cl;

void OnInit(){

   cl=new CClass1;

}

No entanto...

Quantas variantes diferentes podem existir? Um número razoável? 10, 20, 100? Mesmo com 100 variantes, o interruptor funciona mais rapidamente do que o OOP.

Aqui está um guião para comparar o desempenho. Compara o OOP acima mencionado e um simples interruptor com funções (e duas funções são chamadas, uma das chamadas de função pode ser facilmente descartada).

void ff(int z){

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

         ...

         case 99:
         f99();
         break;

      }
     
}
Os resultados (chamada f99):

Arquivos anexados:
test.mq4  9 kb
 
Integer:

Quantas opções diferentes podem existir? Um número razoável? 10, 20, 100? Mesmo com 100 escolhas, o interruptor funciona mais rapidamente do que o OOP.

Gostaria de advertir contra as sobre-generalizações: tal efeito é razoável de esperar em mql, porque utiliza "pseudo-pontos" virtuais - essencialmente trata de se referir à tabela interna (oculta) de endereços reais de hash. Para resolver tais apontadores, é necessário um tempo extra significativo, muito para além do endereçamento directo do ponteiro. Não medi, mas é provável que o mesmo efeito de "estrangulamento" do ponteiro seja encontrado em línguas dotNET e outras implementações semelhantes.

As línguas com indicações "reais" não terão este efeito, a troca perderá por aí - quanto maior for a lista de escolhas.

Portanto, o OOP não tem essencialmente nada a ver com isto.

 
MetaDriver:

Gostaria de advertir contra a sobre-generalização. Tal efeito é razoável esperar em mql, porque utiliza "pseudo-pontos" virtuais - essencialmente tabelas de hash que se referem à tabela de hash interna (oculta) de endereços reais. Para resolver tais apontadores, é necessário um tempo extra significativo, muito para além do endereçamento directo do ponteiro. Não medi, mas é provável que o mesmo efeito de "estrangulamento" do ponteiro seja encontrado em línguas dotNET e outras implementações semelhantes.

Em línguas com indicações "reais" este efeito não acontecerá, a mudança perderá por aí - quanto maior for a lista de escolhas.

Portanto, o OOP não tem essencialmente nada a ver com isto.

É evidente que é apenas o próprio compilador, daí que com uma compilação "correcta" os tempos de execução dos exemplos acima referidos se igualariam.
 
icas:
É evidente que é apenas uma questão do próprio compilador, daí que se os exemplos acima forem compilados "correctamente", os tempos de execução serão iguais.
O conceito de "correcção" depende das regras, pelo que não tem sentido. ;)
 

Vou apontar o erro imediatamente: as funções f estão vazias e completamente recortadas pelo compilador. Ou seja, na realidade não há chamada de função. Também não tenho a certeza a que estado a função ff irá degenerar e se não acabar por estar em linha dentro do loop for, removendo assim até mesmo a chamada de função.

O método virtual, por outro lado, não pode ser cortado - é sempre chamado. Como resultado, num caso o laço está apenas a girar, e no outro caso a chamada está no laço.

Em qualquer teste, é necessário primeiro provar a sua correcção, e só depois ir para os resultados.

 

Aqui está um com uma função não vazia:

Arquivos anexados:
test2.mq4  11 kb
 

Aqui estão todas as funções que são únicas, além disso, chamadas via switch, mais complexas do que um método de classe.

Arquivos anexados:
test3.mq4  12 kb
 
Integer:

Aqui estão todas as funções que são únicas, além disso, chamadas via switch, mais complexas do que um método de classe.

Que confusão...

Já ouviu alguma coisa sobre olining? E que tal um revestimento agressivo?

O que acontece normalmente a corpos de funções simples e o que é que um bom compilador optimizador faz com eles? Isto não é 1995, pois não?

 
MetaDriver:

Gostaria de advertir contra a sobre-generalização. Tal efeito é razoável de esperar em mql, porque usa "pseudo-pontos" virtuais - essencialmente trata de referir-se à tabela interna (oculta) de endereços reais de hash. Para resolver tais apontadores, é necessário um tempo extra significativo, muito para além do endereçamento directo do ponteiro. Não medi, mas é provável que o mesmo efeito de "estrangulamento" do ponteiro seja encontrado em línguas dotNET e outras implementações semelhantes.

Em línguas com indicações "reais" não haverá tal efeito, aí a mudança perderá - quanto maior for a lista de escolhas.

Portanto, o OOP não tem essencialmente nada a ver com isto.

Sim. Aqui está em Dó sustenido:)


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

 

Iniciar qualquer teste provando que está correcto e mede realmente o que afirma medir.

O que é apresentado acima contém erros surpreendentes e mostra a completa falta de compreensão do autor sobre os mecanismos de compilação e como o código funciona.

 
Renat:

Iniciar qualquer teste provando que é correcto e mede realmente o que diz medir.

O que é apresentado acima contém erros surpreendentes e mostra a completa falta de compreensão do autor sobre os mecanismos de compilação e como o código funciona.

Porque devo compreender os mecanismos de compilação? Só para acreditar que um mau resultado é melhor do que um bom? É o resultado que importa.
1234567
Novo comentário
Razão: