El esplendor y la pobreza de la OLP - página 3
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
En realidad, no era el compilador lo que se estaba probando, sino dos métodos para resolver el mismo problema. No importa cómo zumba la nevera, sino cómo se congela.
Es un problema tirado y ruidoso...
Lasfunciones virtuales nunca son inline, así que con la optimización activada no tiene sentido comparar con ejemplos simples si el cambio se hace bien. Esa es una.
¿Quién ha dicho que la OOP es más rápida? Más cómodo, más lógico, pero apenas más rápido. Son dos.
Si no te gusta, no lo uses.
Después hubo dos variantes más de pruebas, 2 - con funciones no vacías, 3 - con funciones únicas, los resultados fueron similares. La variante 1 se siguió realizando en C#, pero el resultado fue el contrario.
He visto estas opciones. Y también encajan en el esquema en línea y están bien optimizados.
La variante con C# muestra otro error engañoso debido a la incomprensión del trabajo del optimizador de código. El código no se mostró y el compilador dotnet también tiene varias veces más métodos de optimización que descifran los casos degenerados de las muestras de prueba como nueces. Acabo de dar un ejemplo de un caso sencillo de conversión de una función virtual en una función regular en casos sencillos. Nosotros también tendremos activada esta optimización (en casos sencillos como el de esta prueba) y tú también verás cómo un método "virtual" supera de repente a uno directo.
Un problema de lanzamiento y ruido...
Lasfunciones virtuales nunca están en línea, por lo que con la optimización activada no tiene sentido comparar con ejemplos simples si el cambio está bien hecho. Esa es una.
¿Quién ha dicho que la OOP es más rápida? Más fácil, más lógico, pero difícilmente más rápido. Son dos.
Si no te gusta, no lo uses.
Bueno, no es un problema en absoluto. Es sólo un experimento con los resultados y una conclusión.
Me gusta, no me gusta. Usar lento en lugar de rápido no es lógico.
He visto estas opciones. Y también encajan en el esquema de inlining y están bien optimizados.
La variante con C# muestra otro error engañoso causado por una mala interpretación del trabajo del optimizador de código. El código no se mostró y el compilador dotnet tiene varias veces más métodos de optimización que pueden descifrar los casos degenerados de los ejemplos de prueba como nueces. Acabo de poner un ejemplo de un caso sencillo de conversión de una función virtual en una función regular en casos sencillos. Nosotros también tendremos activada esta optimización (en casos sencillos como el de esta prueba) y tú también verás cómo un método "virtual" supera de repente a uno directo.
Parece que cualquier resultado que obtenga será erróneo y engañoso.
- ¿Para qué?
- Indio, señor.
(xf Lone Ranger)
Por más que lo he intentado, no hay manera de conseguir que funcione más lento que el método virtual a través de switch. Lo intenté, pero lo siento, no funcionó.
Aquí en el apéndice está la primera prueba de C#. Estos fueron los resultados
Las pruebas vendrán del otro lado. O de nuevo sólo palabras.
En general, sólo me interesan los hechos.
Aunque ya sé que la POO es más lenta, pero proporciona comodidades bastante concretas
Las pruebas vendrán del otro lado.
¿Prueba de qué?
¿Por qué se necesita OOP para escribir juguetes? )
En cualquier caso, es bueno que se haya planteado la cuestión.
Trabajamos constantemente para mejorar el compilador y su optimizador. Ahora nos concentraremos en la optimización de las llamadas a métodos virtuales (muchos métodos virtuales pueden convertirse en métodos directos).