¿La creación de perfiles sin la evaluación comparativa lleva a una microoptimización?

7

Lea primero: Para obtener una definición de los dos términos ("perfilado" y "evaluación comparativa") y la necesidad de distinguirlos, lea esto answer a un question .

Tengo que admitir que hasta que vi Winston Ewert , nunca he pensado en la necesidad de distinguir las dos técnicas. Simplemente creo que el "perfilado" se puede aplicar a diferentes "niveles de escala" de software, y que cuando se aplica en el nivel superior, el código de perfilado en los niveles inferiores debe desactivarse para reducir la sobrecarga agregada.

Después de reflexionar sobre la respuesta, podría haber explicado por qué caí presa de la microoptimización en mi proyecto anterior.

En un esfuerzo por optimizar durante ese proyecto, implementé un perfilador de baja sobrecarga (insertado en el código fuente) que es bueno para generar resultados de perfilado precisos en el nivel de milisegundos. Luego pasé todos los días jugueteando con él y optimicé muchos códigos basados en el resultado del perfilador. Al final, logré reducir la parte cómputo del proyecto de varios segundos a menos de una fracción de segundo.

Lo siguiente que aprendí, para mi horror: cuando el módulo optimizado se usó en un proyecto más grande, E / S y conversión de datos dominaron completamente el cálculo del módulo . La parte de no computación está en el rango de 1-2 segundos, lo que hace que mis esfuerzos de optimización sean discutibles.

Hasta esta fecha, todavía no tengo la oportunidad de hacer una verdadera "evaluación comparativa", aunque voy a intentarlo muy pronto.

Dado que "¿Hiciste el perfil?" se ha convertido en el cliché de StackOverflow y Programmers.SE, ¿existe el peligro de que mi tipo de ignorancia sea realmente prevaleciente entre los demás desarrolladores? ¿Esta ignorancia lleva a micro-optimizaciones en todos los lugares?

    
pregunta rwong 09.05.2011 - 00:53

5 respuestas

6

Por lo que he visto el "¿hiciste tu perfil?" La pregunta siempre viene después de "¿por qué esto funciona tan lento?" así que se realizó el "benchmarking" y el resultado fue "demasiado lento" y ahora estamos tratando de averiguar por qué se está ejecutando tan lentamente, así que vamos y lo "perfilamos".

La vida real suele ser más complicada. La rapidez de su software depende de las decisiones arquitectónicas que tome, de los algoritmos que elija, de si ha identificado o no correctamente y ha resuelto diversos cuellos de botella y restricciones del sistema. Quedarse atascado optimizando un sistema que no está diseñado para el rendimiento es una trampa fácil de caer y puede absorber enormes cantidades de tiempo por una pequeña recompensa. Por otro lado, no todos los programas tienen un alto rendimiento como requisito.

Perfilar y optimizar antes de realizar un punto de referencia, es decir, antes de saber si el rendimiento es adecuado o no, está realmente cayendo en el escenario de optimización prematura.

Me gusta esta cita de Wikipedia :

  

“La primera regla del programa   Optimización: no lo hagas. El segundo   Regla de Optimización del Programa (para   ¡Sólo expertos!): No lo hagas todavía. "-   Michael A. Jackson

    
respondido por el Guy Sirton 09.05.2011 - 01:34
1

El que no honra a los pequeños no es digno de los grandes.

Aunque no haga que la función específica sea significativamente más rápida, puede asegurar algunos ciclos que podrían ayudar al sistema en general. Tomar pequeñas cantidades de tiempo fuera de muchos enlaces en una cadena puede llegar a ser más que simplemente combatir el enlace más débil.

Por supuesto, debes tener cuidado al dedicarle demasiado tiempo. Sin embargo, pequeños ajustes se apilan. Los pequeños ajustes también se hacen mejor mientras tu código está fresco. Por lo general, no aparecerán en un generador de perfiles, ya que son pequeños y son muchos en todas partes.

Primero haz que funcione, luego hazlo rápido. A veces es lo suficientemente rápido, aunque hay muchas oportunidades de mejora.

A veces no es "prematuro" si es difícil hacerlo más tarde.

    
respondido por el Joppe 09.05.2011 - 01:45
1

El perfil debe ser contra escenarios realistas (llame a benchmarking si lo desea). (¿Es eso un "Dugh"?)

Las soluciones

O (n²) superan severamente a O (n log (n)) por un amplio margen dado por conjuntos de datos suficientemente pequeños. Eso es bien conocido.

Los programas que la mayoría de los desarrolladores escriben de primera mano no se escalan a un orden de magnitud superior. Es responsabilidad del gerente de proyecto asegurarse de que todo se pruebe con conjuntos de datos y escenarios de prueba cercanos a la vida real, y de ejecuciones / segundos por módulo cuando sea necesario.

La gestión de riesgos no se trata de ser pesimista. Se trata de considerar escenarios malos y fatales en el diseño y los procedimientos.

    
respondido por el Apalala 09.05.2011 - 02:39
1
  

Dado que "¿Hiciste el perfil?" tiene   convertirse en el cliché de ambos   StackOverflow y Programmers.SE, es   hay un peligro que mi tipo de   la ignorancia es en realidad prevalente entre   compañeros desarrolladores? Hace esta ignorancia   conducir a micro-optimizaciones en todo   los lugares?

Creo que sí, dados los tipos de preguntas y respuestas que viajan sobre estos sitios y la existencia de mitos de perfil .

Es común escuchar a las personas poner código de tiempo en sus rutinas, porque están descontentos o desconcertados con lo que los perfiladores les dicen. También es extremadamente común escuchar a las personas que realizan la microoptimización ya sea que hayan intentado crear perfiles o no.

Creo que parte del problema es la palabra "perfilado" en sí. A menudo se combina con "medir", según mi experiencia, cuando encontrar problemas de rendimiento no es lo mismo que medirlos. Medir puede decir si lo que hiciste marcó una diferencia, pero es una lupa muy difusa para encontrar qué solucionar.

Existe una técnica muy sencilla para localizar rápidamente los problemas de rendimiento de un solo hilo. Una pequeña pero creciente fracción de programadores lo sabe. Se basa en una observación muy simple. Mientras que un programa está haciendo algo que realmente no necesita hacer, puedes ver qué es solo sorprendiéndolo al azar. Si pierdes el tiempo suficiente para que valga la pena arreglarlo, no tendrás que sorprenderlo muchas veces antes de que lo veas. Entonces puedes ver, en detalle preciso, cuál es el problema. Aquí hay más información sobre tema.

    
respondido por el Mike Dunlavey 10.05.2011 - 01:15
0

En realidad soy de la mentalidad opuesta. La forma más sencilla de terminar microajustando innecesariamente una base de código durante horas y lejos de las operaciones de usuario final del mundo real es obsesionarse con los puntos de referencia.

Puede terminar haciendo que la prueba de rendimiento disminuya hasta el doble de tiempo y luego pierda horas con el equipo investigando y ajustándolo nuevamente cuando, en el contexto de la aplicación, la pequeña funcionalidad que se está probando solo toma el 0.01% de el momento, haciendo que tratar de acelerarlo de nuevo sea un esfuerzo inútil.

De hecho, prefiero mantener el rendimiento de una base de código en lugar de "orgánico", ya que al no intentar cimentarlo con puntos de referencia interminables. Como mínimo, si va a agregar pruebas de rendimiento a su sistema, asegúrese de que sean lo suficientemente altos y suficientemente cercanos a lo que sus usuarios realmente hacen con el software y con frecuencia. En realidad, no creo que un sistema de compilación automatizado omita mucho al omitir las pruebas de rendimiento siempre y cuando existan pruebas de unidad / integración para la corrección, y trabajo en áreas críticas para el rendimiento.

Mi antigua empresa realizó todas estas pruebas de rendimiento para cosas que estaban tan lejos de las operaciones finales del usuario, como simplemente cronometrar el tiempo que lleva llamar una función en una interfaz de bajo nivel un millón de veces y obsesionarme con algunas fluctuaciones de rendimiento esas áreas son contraproducentes en comparación con la creación de perfiles de la aplicación frente a un caso de uso del mundo real. Incluso llegó al punto en el que las personas estaban perdiendo innumerables horas de trabajo de hombre al investigar las demoras en las pruebas de rendimiento de bajo nivel, mientras que las operaciones de alto nivel de usuarios de la aplicación se estaban volviendo perceptiblemente más rápidas ... aún los desarrolladores estaban obsesionados con el hecho de obtener un valor fuera de la propiedad tomó un 30% más de tiempo que cuando comenzaron, a pesar de que eso tuvo muy poco impacto en el usuario. Preferiría que hicieran un perfil de la aplicación que estos micro-puntos de referencia.

Los hotspots tienden a cambiar a casos raros a medida que las cosas se vuelven más eficientes en las rutas comunes de ejecución de casos, y en esa experiencia anterior, muchos desarrolladores perdieron tiempo y energía innecesarios tratando de optimizar los casos raros obsesionados con estas pruebas de rendimiento de adolescentes. Tan importante como medir, si no más, es comprender a fondo cómo se usa comúnmente el software. De lo contrario, podríamos estar midiendo / comparando y ajustando las cosas incorrectas y, en el peor de los casos, haciendo que lo que los usuarios realmente hacen sea más eficiente en el proceso.

Para mí, la verdadera prueba de fuego de si está gastando su tiempo de optimización de manera productiva es si en realidad está midiendo casos de uso en el mundo real que los usuarios del software aplican comúnmente y no toman puñaladas en la oscuridad (al menos midiendo ). Por lo general, los más contraproducentes en este sentido son los que están más alejados del lado del usuario, al no entender los escenarios de apelación y uso de casos comunes entre los usuarios del software.

Dicho esto, creo que la "microoptimización" se utiliza más que el perfilado. Si, por "micro", eso significa una optimización sin impacto en el usuario, entonces incluso las mejoras algorítmicas sustanciales deberían considerarse "micro", pero no es así como se usa normalmente. A menudo, "micro" se usa indistintamente con "contraproducente", cuando algunas de las optimizaciones más fructíferas y productivas no provienen de avances algorítmicos sino de algoritmos prácticos que aplican microoptimizaciones efectivas (por ejemplo, una mejor localidad de referencia). Realmente no me importa si es un ajuste algorítmico o de bajo nivel de cómo se disponen los bits y los bytes en memoria o multithreading o SIMD. Todo lo que debería importar es si hay una diferencia real, y no para una función minúscula en el sistema que se invoca con poca frecuencia, sino para el usuario real del software.

    
respondido por el user204677 03.12.2017 - 20:14

Lea otras preguntas en las etiquetas