que - performance sinonimo
Rendimiento vs legibilidad (14)
Al leer esta pregunta , encontré esto como (tenga en cuenta las comillas) "código" para resolver el problema (eso es perl por cierto).
100,{)..3%!''Fizz''*/5%!''Buzz''*+/or}%n*
Obviamente, este es un ejemplo intelectual sin implicaciones reales (espero nunca ver eso en el código real en mi vida) pero, cuando tiene que hacer la elección, ¿cuándo sacrifica la legibilidad del código para el rendimiento? ¿Aplica solo el sentido común, lo hace siempre como último recurso? ¿Cuáles son tus estrategias?
Editar: Lo siento, al ver las respuestas, podría haber expresado mal la pregunta (el inglés no es mi lengua materna). No me refiero a rendimiento vs legibilidad solo después de haber escrito el código, antes de escribirlo también pregunto. A veces puede prever una mejora en el rendimiento en el futuro haciendo un diseño más oscuro o proporcionando algunas propiedades que harán que su clase sea más oscura. Puede decidir utilizar múltiples hilos o solo uno porque espera la escalabilidad que dichos hilos pueden proporcionarle, incluso cuando eso haga que el código sea mucho más difícil de entender.
Los programas deben estar escritos para que las personas los lean, y solo de manera incidental para que las máquinas los ejecuten.
- Abelson & Sussman, SICP
Los programas bien escritos son probablemente más fáciles de perfilar y, por lo tanto, mejoran el rendimiento .
"La optimización temprana es la raíz de todo mal." - Donald Knuth
Aplico el sentido común: este tipo de cosas es solo una de las trillones de compensaciones que implica la ingeniería, y tiene pocas características especiales que yo pueda ver.
Pero para ser más específicos, la abrumadora mayoría de personas que hacen cosas raras e ilegibles en nombre del rendimiento las están haciendo prematuramente y sin medidas.
Diría que solo debería sacrificar la legibilidad para el rendimiento si hay un problema de rendimiento comprobado que es significativo. Por supuesto, "significativo" es la captura allí, y lo que es significativo y lo que no debe ser específico del código en el que estás trabajando.
Elija la legibilidad sobre el rendimiento a menos que pueda demostrar que necesita el rendimiento.
La legibilidad es más importante. Con las computadoras modernas, solo las rutinas más intensas de las aplicaciones más exigentes deben preocuparse demasiado por el rendimiento.
Mi proceso para situaciones donde creo que el rendimiento puede ser un problema:
- Hazlo funcionar.
- Acláralo.
- Prueba el rendimiento
- Si hay problemas de rendimiento significativos: refactor para la velocidad.
Tenga en cuenta que esto no se aplica a las decisiones de diseño de nivel superior que son más difíciles de cambiar en una etapa posterior.
Siempre comienzo con la versión más legible que puedo pensar. Si el rendimiento es un problema, me refactorio. Si la versión legible hace que sea difícil generalizar, me refactorio.
La clave es tener buenas pruebas para que la refactorización sea fácil.
Veo la legibilidad como el número 1 más importante en el código, aunque funciona correctamente es un segundo muy cercano.
Siempre debes buscar la legibilidad primero. La forma de un sistema generalmente evolucionará a medida que lo desarrolle, y los cuellos de botella de rendimiento real serán inesperados. Solo cuando se ejecuta el sistema y se puede ver evidencia real, tal como lo proporciona un generador de perfiles u otra herramienta similar, se revelará la mejor forma de optimizar.
"Si tienes prisa, toma el camino más largo".
en momentos en que la optimización es necesaria, prefiero sacrificar la compacidad y mantener la mejora del rendimiento. Perl obviamente tiene algunas aguas profundas para buscar la concisión / relación de rendimiento, pero tan lindo como es escribir frases ingeniosas, la persona que viene a mantener su código (que en mi experiencia, usualmente soy yo mismo 6 meses después ) podría preferir algo más en el estilo expandido, como se documenta aquí:
La legibilidad siempre gana. Siempre. Excepto cuando no lo hace Y eso debería ser muy raro.
de acuerdo con todo lo anterior, pero también:
cuando decides que quieres optimizar:
- Arreglar aspectos algorítmicos antes de la sintaxis (por ejemplo, no hacer búsquedas en arreglos grandes)
- Asegúrate de demostrar que tu cambio realmente mejoró las cosas, mide todo
- Comente su optimización para que el siguiente tipo que vea esa función no la simplifique de nuevo desde donde comenzó
- ¿Puede precomputar los resultados o mover el cálculo a donde se puede hacer de manera más efectiva (como un db)
en efecto, mantenga la legibilidad siempre que pueda: encontrar el error oculto en el código optimizado es mucho más difícil y molesto que en el código simple y obvio
Hay excepciones a la regla de optimización prematura. Por ejemplo, cuando se accede a una imagen en la memoria, la lectura de un píxel no debe ser una función fuera de línea. Y al proporcionar operaciones personalizadas en la imagen, nunca lo haga así:
typedef Pixel PixelModifierFunction(Pixel);
void ModifyAllPixels(PixelModifierFunction);
En cambio, permita que las funciones externas accedan a los píxeles en la memoria, aunque es más feo. De lo contrario, está seguro de escribir código lento que tendrá que refactorizar más tarde de todos modos, por lo que está haciendo un trabajo extra.
Al menos, eso es cierto si sabes que vas a tratar con imágenes grandes.
Mi respuesta favorita a esta pregunta es:
- Hazlo funcionar
- Hacer lo correcto
- Hazlo rápido
En el ámbito de las cosas, a nadie le importa una mierda la legibilidad, excepto el siguiente tonto desafortunado que tiene que encargarse de su código. Sin embargo, dicho eso ... si usted es serio acerca de su arte, y esta es una forma de arte, siempre se esforzará por hacer que su código sea lo más posible para el formante mientras aún es legible por otros. Mi amigo y mentor (que es un BADASS en todos los sentidos) una vez me dijo gentilmente en una revisión de código que "el tonto escribe código que solo ellos pueden entender, el genio escribe código que cualquiera puede entender". No estoy seguro de dónde sacó eso, pero me ha quedado grabado.