Sobretaxa para a OLP

 

Em conexão com uma tarefa de recursos intensivos, surgiu uma questão - qual é a sobrecarga do uso do OOP em comparação com a programação processual convencional.

Alguém já fez tais testes?

Estou interessado na diferença entre:

  1. Chamada de função com parâmetros
  2. Chamada de função sem parâmetros
  3. Macrochamada com funcionalidade da função acima
  4. Chamada de função - método de uma classe
  5. Chamada de função virtual

 

De que tipo de despesas gerais estamos falando?

Se estamos falando de código de máquina, então, tanto quanto sei, a função virtual chama o procedimento indiretamente, através da tabela de funções virtuais. E no caso de funções normais, é uma chamada direta. Acho que há muito poucas despesas gerais.

A sobrecarga do programador é muito mais importante - escrita e manutenção de códigos, correção de bugs...

 

As funções sem parâmetros são mais rápidas que as funções com parâmetros.

 
Dmitry Fedoseev:

As funções sem parâmetros são mais rápidas que as funções com parâmetros.


É claro, eu estou batendo em montador há 2 anos )) É verdade, para processadores embutidos, mas C++ é sempre C++. Mesmo uma função sem parâmetros tem um prólogo e um epílogo, o que também leva tempo.

A maneira mais rápida, é claro, é usar uma macro projetada para parecer uma função. É uma pena que não existam funções em linha na MQL, mas as macros são um substituto para

 
George Merts:

De que tipo de despesas gerais estamos falando?

Se estamos falando de código de máquina, então, tanto quanto sei, a função virtual chama o procedimento indiretamente, através da tabela de funções virtuais. E no caso de funções normais, é uma chamada direta. Acho que há muito poucas despesas gerais.

As despesas gerais do programador são muito mais importantes - escrita e manutenção de códigos, correção de erros...


Naturalmente, não nos importamos com o tempo de execução - esses quilobytes extras não importam. Nós não nos importamos com esses kilobytes extras.

 

Uma macro seria, naturalmente, a mais rápida.

 
Alexey Volchanskiy:

A maneira mais rápida é, naturalmente, uma macro projetada como uma função. É pena que a MQL não tenha funções em linha, mas uma macro seria um substituto

Rinat disse que a MT tem uma função em linha séria, e dá bons resultados.

 
George Merts:

Rinat disse que o MT - um inliner sério funciona, e dá bons resultados.


Sim, de acordo com minhas observações pessoais, em MT4 o trabalho do inliner depende do tamanho da pilha (memória alocada para as variáveis na pilha) e do número de variáveis.
Mas no MT5 a dependência do tamanho da pilha parece ter sido removida e o otimizador é mais assistente lá em geral.

 
Alexey Volchanskiy:

Em conexão com uma tarefa de recursos intensivos, surgiu uma questão - qual é a sobrecarga do uso do OOP em comparação com a programação processual convencional.

Alguém já fez tais testes?

Estou interessado na diferença entre:

  1. Chamada de função com parâmetros
  2. Chamada de função sem parâmetros
  3. Macrochamada com funcionalidade da função acima
  4. Chamada de função - método de uma classe
  5. Chamada de função virtual

Se as bibliotecas OOP prontas para uso estiverem disponíveis, isto reduz o tempo de desenvolvimento da aplicação. A velocidade de execução pode diminuir ao chamar a função virtual.

A única nuança é a disponibilidade de boas bibliotecas do OOP.

"Biblioteca padrão" viola meu senso de beleza e me faz ir à DLL e codificar silenciosamente em C++


 
George Merts:

Rinat disse que em MT - um inliner sério funciona, e dá bons resultados.

Sim, o inliner é muito agressivo e automático.

O otimizador de código x64 também é uma cabeça acima da versão 32-bit (este ramo está completamente parado e não desenvolvido). Além disso, o otimizador x64 sabe como desenrolar a maioria das funções virtuais em chamadas diretas e em linha. Afinal de contas, as funções virtuais são muitas vezes degeneradas.

Mas onde a verdadeira sobrecarga está nas operações de referência e no controle de índices dinâmicos. Eles têm que ser controlados o tempo todo.

 
Alexey Volchanskiy:

Em conexão com uma tarefa de recursos intensivos, surgiu uma questão - qual é a sobrecarga do uso do OOP em comparação com a programação processual convencional.

Naturalmente, as características agradáveis do OOP são caras em recursos e depuração demorada. OOP faz sentido apenas como um conveniente invólucro de texto ou em caso de uso mínimo na inicialização em tempo de execução... Na verdade, o OOP foi apenas uma coisa de marketing da Microsoft para aumentar os custos do horário de trabalho dos programadores e para estimular a compra de equipamentos mais avançados. E eles mesmos não são tolos e escrevem todo o software em C e assembler.

Razão: