O esplendor e a pobreza da OLP - página 3
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Na verdade, não era o compilador que estava a ser testado, mas dois métodos para resolver o mesmo problema. Não importa como o frigorífico cantarola, mas sim como congela.
É um problema atirado fora e é barulhento...
Asfunções virtuais nunca estão em linha, por isso com a optimização activada não vale a pena comparar com exemplos simples se o interruptor for bem feito. Esta é uma delas.
Quem disse que o OOP é mais rápido? Mais conveniente, mais lógico, mas dificilmente mais rápido. São dois.
Se não gostar, não o utilize.
Depois disso, houve mais duas variantes de testes, 2 - com funções não vazias, 3 - com funções únicas, os resultados foram semelhantes. A variante 1 foi ainda conduzida em C#, mas o resultado foi o oposto.
Tenho visto estas opções. E também eles se enquadram no esquema em linha e estão bem optimizados.
A variante com C# mostra outro erro enganador devido a uma má compreensão do trabalho do optimizador de código. O código não foi mostrado e o compilador dotnet também tem várias vezes mais métodos de optimização que racham os casos degenerados das amostras de teste como porcas. Dei apenas um exemplo de um caso simples de conversão de uma função virtual numa função regular em casos simples. Também teremos esta optimização (em casos simples como este teste) activada e também verá como um método "virtual" ultrapassa subitamente um método directo.
Um problema e barulho atirado para fora...
Asfunções virtuais nunca estão em linha, por isso com a optimização activada não vale a pena comparar com exemplos simples se o interruptor for bem feito. Esta é uma delas.
Quem disse que o OOP é mais rápido? Mais fácil, mais lógico, mas dificilmente mais rápido. São dois.
Se não gostar, não o utilize.
Bem, não é um problema de todo. É apenas uma experiência com os resultados e uma conclusão.
Eu gosto, eu não gosto. Usar lento em vez de rápido não é lógico.
Tenho visto estas opções. E também eles se enquadram no esquema de revestimento e estão bem optimizados.
A variante com C# mostra outro erro enganador causado por uma má compreensão do trabalho do optimizador de código. O código não foi mostrado e o compilador dotnet tem várias vezes mais métodos de optimização que podem rachar casos degenerados de exemplos de testes como porcas. Dei-vos apenas um exemplo de um caso simples de conversão de uma função virtual numa função regular em casos simples. Também teremos esta optimização (em casos simples como este teste) activada e também verá como um método "virtual" ultrapassa de repente um método directo.
Parece que qualquer que seja o resultado que eu obtenha, será errado e enganador.
- Para quê?
- Índio.
(xf Lone Ranger)
Por mais que eu tenha tentado, não há maneira de o fazer trabalhar mais lentamente do que o método virtual através do interruptor. Tentei, mas lamento, mas não funcionou.
Aqui, no apêndice, encontra-se o primeiro teste C#. Aqui estão os resultados
As provas virão do outro lado. Ou, mais uma vez, apenas palavras.
De um modo geral, só estou interessado em factos.
Embora eu já saiba que o OOP é mais lento, mas oferece conveniências bastante concretas
As provas virão do outro lado.
Prova de quê?
Porque é que precisa do OOP para escrever brinquedos? )
Em qualquer caso, é bom que a questão tenha sido levantada.
Estamos constantemente a trabalhar para melhorar o compilador e o seu optimizador. Vamos agora concentrar-nos na optimização de chamadas de métodos virtuais (muitos métodos virtuais podem ser transformados em métodos directos).