Rendimiento vs legibilidad

Question

Lectura this question 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, esto es un ejemplo intelectual sin real (espero no ver que en código real en mi vida) implicaciones pero, cuando se tiene que tomar la decisión, ¿cuándo sacrificar 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 que podría haber expresado la pregunta mal (Inglés no es mi lengua materna). No me refiero a rendimiento vs legibilidad solo después de usted ha escrito el código, pregunto antes de escribirlo también. 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.

Answer 1

Mi proceso para situaciones en las que creo el rendimiento puede ser un problema:

1. hacer que funcione.
2. Aclare.
3. Pruebe el rendimiento.
4. 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.

Answer 2

Siempre empiezo con la versión más fácil de leer que se me ocurre. 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 refabricació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 cercano.

Answer 3

Elija la legibilidad sobre el rendimiento a menos que pueda demostrar que necesita el rendimiento.

Answer 4

Yo 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.

Answer 5

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.

Answer 6

Me aplico el sentido común - este tipo de cosas es solo una de las compensaciones trilladas 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 extrañas e ilegibles en nombre del rendimiento las están haciendo prematuramente y sin medidas.

Answer 7

Siempre debe ir primero a la legibilidad. 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."

Answer 8

Los programas se deben escribir para que las personas los lean, y solo de manera incidental para las máquinas que se ejecutarán.
  — Abelson & Sussman, SICP

programas bien escritos son probablemente más fácil profile and hence improve performance.

Answer 9

"La optimización prematura es la raíz de todo mal". - Donald Knuth

Answer 10

en momentos en que la optimización es necesaria, prefiero sacrificar 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 para mantener tu código (quien en mi experiencia, usualmente soy yo mismo 6 meses después)) podrían preferir algo más en el estilo ampliado, tal como se documenta aquí:

http://www.perl.com/pub/a/2004/01/16/regexps.html

Answer 11

de acuerdo con todo lo anterior, pero también:

cuando se decide que desea optimizar:

1. Fix aspectos algorítmicos antes de la sintaxis (por ejemplo, no realizar búsquedas en grandes series)
2. Asegúrese de probar que su cambio realmente mejoró las cosas, mida todo
3. Comente su optimización para que el siguiente tipo que vea esa función no lo simplifique de nuevo a donde comenzó desde
4. ¿Se puede calcular previamente los resultados o mover el cómputo de donde se puede hacer de manera más eficaz (como una base de datos)

en efecto, mantener la legibilidad tanto tiempo como sea posible - para encontrar el insecto oscuro en código optimizado es mucho más difícil y molesto que en el simple código obvio

Answer 12

La legibilidad siempre gana. Siempre. Excepto cuando no lo hace Y eso debería ser muy raro.

Answer 13

Existen 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 cuando se proporciona para operaciones personalizadas en la imagen, no hacerlo de esta manera:

typedef Pixel PixelModifierFunction(Pixel); 

void ModifyAllPixels(PixelModifierFunction); 

su lugar, vamos funciones externas acceder 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 sabe que va a tratar con imágenes grandes.

Answer 14

Mi respuesta favorita a esta pregunta es:

1. hacer que funcione
2. hacer lo correcto
3. que sea rápido

En el ámbito de cosas que nadie da una mierda 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 por formante mientras que otros puedan seguir leyéndolo. 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.

Reference