¿Por qué debería preocuparme por el micro rendimiento y la eficiencia?

En la práctica, el rendimiento rara vez es un problema que debe gestionarse con ese nivel de detalle. Vale la pena vigilar la situación si sabe que va a almacenar y manipular grandes cantidades de datos, pero de lo contrario, tiene razón y está mejor, manteniendo las cosas simples.

Una de las trampas más fáciles de caer, especialmente en C y C ++ donde tiene un control tan preciso, es la optimización demasiado pronto y en un nivel demasiado fino. En general, la regla es: A) no optimice hasta que descubra que tiene un problema, y B) no optimice nada que no haya demostrado ser un área problemática mediante el uso de un generador de perfiles.

Un corolario de B) es: los programadores son notoriamente malos para predecir dónde se encuentran sus cuellos de botella en el rendimiento, aunque, para uno, creen que son buenos en eso. Use un generador de perfiles y optimice las partes que son lentas, o cambie los algoritmos si una sección del código se llama demasiadas veces, por lo que está causando un problema.

Creo que todo en tu lista es una microoptimización, que generalmente no debería ser analizada, excepto por

  

utilizando un algoritmo O (n * n) vs O (NlogN) en una lista de 100 elementos

que creo que debería ser mirado. Claro, esa lista contiene 100 artículos en este momento, y todo es rápido para la pequeña n , pero estaría dispuesto a apostar pronto que el mismo código se reutilizará para una lista de varios millones de líneas, y el código todavía tendrá que funcionar de manera razonable.

Elegir el algoritmo correcto es nunca una microoptimización. Nunca se sabe qué tipo de datos se utilizarán en el mismo código durante dos meses o dos años más tarde. A diferencia de las "microoptimizaciones" que son fáciles de aplicar con la guía de un generador de perfiles, los cambios de algoritmo a menudo requieren un rediseño significativo para hacer un uso efectivo de los nuevos algoritmos. (Por ejemplo, algunos algoritmos requieren que los datos de entrada ya estén ordenados, lo que podría forzarle a modificar partes significativas de sus aplicaciones para garantizar que los datos permanezcan ordenados)

Hace muchísimo tiempo, en mi primer trabajo, escribí código para sistemas integrados. Estos sistemas utilizaron 8086 microprocesadores, y tenían memoria limitada. Utilizamos el compilador Intel C Un sistema que construí necesitaba para acceder a una matriz de estructuras en 3-d. Lo construí tal como el libro me dijo: llame a malloc para las 3 dimensiones, luego asigne filas para la siguiente dimensión, luego calloc para los nodos finales.

Fue bastante complicado (para mí en ese momento), tuve que hacer ajuste de curvas, control de procesos ANOVA y análisis de Chi cuadrado. No había bibliotecas que hicieran esto por nosotros; Tuvimos que escribirlo todo y encajarlo todo en el 8086.

El sistema corría como un perro. Después de un rápido perfilado, descubrí que uno de los mayores problemas era el asignador. Para solucionar el problema, abandoné todas las llamadas a malloc e hice mi propia gestión de memoria de un gran bloque de memoria.

En otro caso en el mismo trabajo, el cliente se quejaba del tiempo de respuesta en su sistema de control de proceso estadístico. El equipo anterior a mí había diseñado un sistema de "software PLC" donde los operadores podían usar una lógica booleana para combinar señales e interruptores de disparo. Lo escribieron en un lenguaje simplificado, lo que hoy llamaríamos un "lenguaje específico de dominio". Como recuerdo, parecía ((A1 + B1) > 4) AND (C1 > C2) y así sucesivamente.

El diseño original analizó e interpretó esa cadena cada vez que se evaluó. En nuestro pequeño procesador, esto consumía mucho tiempo, y significaba que el controlador del proceso no podía actualizarse tan rápido como el proceso se estaba ejecutando.

Le eché un nuevo vistazo y decidí que podía traducir esa lógica en código de ensamblaje, en tiempo de ejecución. Lo analicé una vez y luego, cada vez que se ejecutó, la aplicación entró en una función generada dinámicamente. Algo así como algunos virus lo hacen hoy, supongo (pero no lo sé, realmente no sé). El resultado fue un aumento del rendimiento de 100 veces, lo que hizo que el cliente y mi jefe se sintieran realmente felices.

El nuevo código no era tan fácil de mantener, ya que había creado un compilador personalizado. Pero la ventaja de rendimiento superó la desventaja de mantenimiento.

Más recientemente, estaba trabajando en un sistema que necesitaba analizar una mosca XML de forma dinámica. Archivos más grandes tomarían considerablemente más tiempo. Esto fue muy sensible al rendimiento; un análisis demasiado lento podría hacer que la interfaz de usuario se vuelva completamente inutilizable.

Este tipo de cosas surgen todo el tiempo.

Entonces ... a veces quieres un código fácil de escribir y fácil de escribir. A veces quieres un código que se ejecuta rápidamente. La compensación es la decisión de ingeniería que debe tomar en cada proyecto.

Si está procesando imágenes grandes e iterando sobre cada píxel, entonces el ajuste de rendimiento puede ser crítico.

Déjame contarte un poco sobre el por qué detrás de la cultura.

Si estás más cerca de 40 que de 20, y has estado programando para vivir durante tu vida adulta, entonces creciste cuando C ++ era realmente el único juego en la ciudad, las aplicaciones de escritorio eran la norma, y el hardware todavía estaba muy retrasado en términos de ancho de banda / capacidades de rendimiento.

• Solíamos tener que hacer estupendos trucos de programación para poder leer archivos grandes (> 2G) ...
• Solíamos preocuparnos por tamaño ejecutable ...
• Solíamos preocuparnos por la cantidad de memoria que consumían nuestros programas ...
• Con frecuencia tomamos decisiones algorítmicas de compensación de tiempo vs. espacio ...
• Incluso en el back-end, tuvimos para escribir programas CGI en C o C ++ para cualquier cosa para manejar un no decente. de RPS ... Fue varios órdenes de magnitud más rápido.
• ¡Solíamos ejecutar pruebas sobre los méritos de rendimiento entre delphi / c ++ / vb!

Muy pocas personas tienen que preocuparse por estas cosas hoy.

Sin embargo, hace 10 años todavía tenía que preocuparse por la descarga de su software a través de un módem de 56 kb, y su ejecución en una PC de 5 años ... ¿Recuerda qué tan malas fueron las PC en 1996? Piense en términos de 4 GB de disco duro, un procesador de 200 MHz y 128 MB de RAM ...

¿Y los servidores de hace 10 años? El servidor de Dell de "próxima generación" costó $ 2000 y vino con 2 (!) Procesadores Pentium de 1Ghz, 2Gb o Ram, y un disco duro de 20Gb.

Era simplemente un juego de pelota diferente , y todos esos ingenieros "senior" que tienen 10 años de experiencia (los tipos que probablemente respondan tus preguntas), se cortan los dientes en ese ambiente.

ya hay 10 respuestas aquí y algunas son realmente buenas, pero debido a que este es un motivo personal mío ...

la optimización prematura que a) lleva mucho más tiempo que una solución simple b) introduce más código donde la solución simple habría sido la mitad del tamaño y la mitad de la complejidad, yc) hace que las cosas menos legibles se eviten ABSOLUTAMENTE. Sin embargo, si un desarrollador puede elegir entre usar std :: map o std :: vector y elige la colección errónea por pura ignorancia para el rendimiento, es tan malo, si no peor, que la optimización prematura. ¿Qué pasaría si pudiera cambiar un poco su código hoy, mantener la legibilidad, mantener la misma complejidad, pero hacerlo más eficiente, lo haría? ¿O lo llamaría "optimización prematura"? Encuentro que mucha gente ni siquiera lo pensaría de una manera u otra.

Una vez fui el tipo que aconsejó "microoptimización" que requería muy poco cambio y recibí la misma respuesta que usted acaba de decir: "no debería optimizar demasiado pronto. Hagámoslo funcionar y nosotros ' Lo cambiaré más tarde si hay un problema de rendimiento ". Tomó varios lanzamientos antes de que lo reparáramos. Y sí, fue un problema de rendimiento.

Si bien la optimización temprana puede no ser buena, creo que es muy beneficioso si las personas escriben código para entender qué va a hacer ese código y no simplemente ignoren cualquier pregunta que resulte en la notación O (x) como "optimización" ". Hay mucho código que puede escribir ahora y con un poco de reflexión sobre el rendimiento, evite el 80% de los problemas en el futuro.

También tenga en cuenta que muchos de los problemas de rendimiento no van a ocurrir en su entorno y no de inmediato. Algunas veces tendrás un cliente que supera el límite u otro desarrollador decide construir sobre tu marco y aumentar la cantidad de objetos en 10 veces. Ahora, con algunas reflexiones sobre el rendimiento, podría evitar un rediseño muy costoso más adelante. Y si el problema se encuentra después de que el software se haya lanzado oficialmente, incluso una solución simple es 20 veces más cara de aplicar.

En conclusión, tener en cuenta el rendimiento en todo momento ayuda a desarrollar buenos hábitos. Los cuales son tan importantes como tener un código limpio, lo más simple posible y organizado.

Sospecho que mucho de lo que está viendo es un simple error de muestreo. Cuando las personas se enfrentan a situaciones sencillas, escriben códigos y eso es todo. Hacen preguntas cuando están lidiando con algo relativamente complicado, como la necesidad de optimizar, especialmente en una situación en la que no es necesariamente obvio que la optimización sería necesaria.

Dicho esto, indudablemente también implica una optimización prematura. De manera correcta o no, C y C ++ tienen una reputación de desempeño, que tiende a atraer a las personas que se preocupan por el desempeño, incluidos aquellos que pueden hacer la optimización tanto para disfrutar como porque realmente es necesario.

Algunas de las otras respuestas mencionan sistemas integrados , y me gustaría ampliar esto.

Hay muchos dispositivos que contienen procesadores de gama baja, por ejemplo: el controlador de la caldera en su casa, o una simple calculadora de bolsillo, o las docenas de chips dentro de un automóvil moderno.

Para ahorrar dinero, estos pueden tener cantidades de memoria flash (para almacenar el código) y RAM que parecen pequeñas para aquellos que solo han escrito código para PC o teléfonos inteligentes. Para ahorrar energía, pueden funcionar a velocidades de reloj relativamente bajas.

Para tomar un ejemplo, la familia STM32 de microcontroladores va desde 24 MHz, 16 KB flash y 4 KB de RAM , hasta 120 MHz, 1 MB flash y 128 KB RAM .

Al escribir código para chips como estos, ahorra mucho tiempo si pretende que su código sea lo más eficiente posible. Obviamente, la optimización prematura sigue siendo una mala idea; pero con la práctica, aprenderá cómo los problemas comunes se pueden resolver rápidamente y / o con recursos mínimos, y codificar en consecuencia.

Estos son esencialmente lenguajes de bajo nivel, cuando uno se encuentra con un caso de rendimiento patológico en el que un detalle que no importaría el 99% del tiempo está causando el cuello de botella, uno realmente tiene la oportunidad de trabajar directamente alrededor del problema (a diferencia de la mayoría de los otros idiomas); pero, por supuesto, a menudo, la forma más efectiva de hacerlo no es evidente de inmediato. Por lo tanto, la mitad de las preguntas extrañas / interesantes de micro-optimización que se hacen aquí.

La otra mitad proviene de aquellos que sienten curiosidad por lo cerca que pueden llegar al metal. Estos son esencialmente lenguajes de bajo nivel, después de todo ...

El rendimiento siempre es un tema candente cuando se trata de C y C ++. Con respecto a lo lejos que debe ir uno, siempre puede volverse loco hasta el punto de alinear el ASM, o usar la aritmética de punteros para una iteración más rápida. Sin embargo, llega un momento en el que uno pasa tanto tiempo optimizando que el trabajo en el desarrollo del programa general se detiene.

Al tratar con estos problemas, hay un rendimiento del programador y del código. En cuál de estos enfocarse siempre surgirán preguntas interesantes. Al final, la pregunta más importante es qué tan notable es para el usuario. ¿Trabajará el usuario con datos que crean matrices con cientos o miles de elementos? En este caso, la codificación para hacer las cosas rápidamente puede hacer que su usuario se queje de que las operaciones estándar del programa son lentas.

Luego está el usuario que trabajará con pequeñas cantidades de datos. Unos pocos archivos aquí y allá, donde hacer cosas como la ordenación y las operaciones de archivos no serán tan perceptibles para el usuario si está utilizando funciones de nivel superior que facilitan las cosas para mantenerlas al costo de cierto rendimiento.

Este es solo un pequeño ejemplo de los problemas con los que se encontrará. Otros asuntos incluyen el hardware del usuario objetivo. Vas a tener que preocuparte mucho más por el rendimiento si tratas con sistemas embebidos, luego si tus usuarios tienen, por ejemplo, máquinas de doble núcleo con gigas de RAM.

¿Por qué los programadores se preocupan tanto? Hay ideas tontas poblando sus cabezas, como resolver problemas de rendimiento antes de que sepan que los tienen, y no entender cuando están adivinando .

Es complicado porque, según mi experiencia, hay algunos problemas de rendimiento que uno debería pensar con anticipación. Se necesita experiencia para saber cuáles son.

Dicho esto, el método que uso es similar al tuyo, pero no es el mismo:

1. Comience con el diseño más simple posible. En particular, la estructura de datos debe ser lo más normalizada y mínima posible. En la medida en que tenga redundancia inevitable, uno debe ser tímido de las notificaciones como una forma de mantenerla coherente. Es mejor tolerar la inconsistencia temporal y repararla con un proceso periódico.

2. Cuando el programa está en desarrollo, realice ajustes de rendimiento periódicamente, ya que los problemas de rendimiento tienen una manera de introducirse silenciosamente. El método que utilizo es pausas aleatorias , porque creo que es la mejor.

Aquí hay un ejemplo de golpe por golpe de lo que quiero decir.

Para ser honesto, depende de cuál sea tu objetivo y si estás programando profesionalmente o como un pasatiempo.

Hoy en día, las computadoras modernas son máquinas realmente poderosas. Independientemente de las operaciones básicas que decida hacer, ya sea que intente micro optimizarlas o no, estas pueden hacer su trabajo notablemente rápido. Pero, por supuesto, si está haciendo otra cosa (por ejemplo, supercomputación para campos como la física o la química), es posible que desee optimizar todo lo que quiera.

Los primeros programadores de MIT no nacieron para hacer cosas increíbles; Comenzaron a simplificar y potenciar los algoritmos existentes. Su orgullo fue hacer que 2 + 2 otorguen cuatro en dos segundos menos que el algoritmo existente (eso es solo un ejemplo, entiendes la idea). Constantemente intentaron usar menos tarjetas perforadas en sus máquinas TI-83 para obtener un mejor rendimiento.

Además, si está programando para sistemas embebidos, entonces ciertamente debe vigilar el rendimiento micro. No desea tener un reloj digital lento que marque 5 segundos nanosegundos antes que otro reloj digital.

Finalmente, si usted es un programador aficionado, no hay problema en optimizar los detalles más pequeños, aunque su programa es rápido. No es necesario, pero ciertamente es algo en lo que puedes trabajar y aprovechar la oportunidad de aprender más. Si está trabajando profesionalmente en un software, no puede darse ese lujo a menos que sea extremadamente necesario.

  

utilizando un algoritmo O (N2) vs O (NlogN) en una lista de 100 elementos.

Recientemente estuve en una situación similar. Tuve una gran variedad de artículos. En el caso esperado, había dos (!) Elementos en la lista, e incluso en el peor de los casos no espero más de cuatro u ocho.

Necesitaba ordenar esa lista. Resulta que, al reemplazar std::sort con una red de clasificación (esencialmente una gran cantidad de if s anidada) se eliminó un gran porcentaje del tiempo de ejecución (no recuerdo el número, pero fue algo así como 10-20%). Este es un beneficio enorme de una microoptimización, y el código es absolutamente crítico para el rendimiento.

Por supuesto, solo hice esto después de perfilar. Pero el punto es que si utilizo un lenguaje que es tan inconveniente y complejo como C ++ (sin mencionar sus reglas exasperadamente complejas para la resolución de sobrecargas), quiero obtener todos los beneficios.

Uso acumulativo de energía

Hay una respuesta que siempre creo que falta en esta discusión y que me molesta un poco: uso de energía acumulativa .

Claro, tal vez no importe mucho si escribe su programa en un lenguaje interpretado de alto nivel y lo deja correr en un navegador con un par de capas de direccionamiento indirecto, o si su bucle toma 0.01 segundos en lugar de 0.001 segundos. Nadie notará, es decir, ningún usuario individual notará.

Pero cuando decenas de miles, o incluso millones de usuarios en algunos casos usan su código, toda esa ineficiencia adicional se suma. Si su herramienta impide que una CPU ingrese al estado de reposo por solo diez segundos por día, y un millón de usuarios la usen, su algoritmo ineficiente solo consumirá 140 kWh adicionales ^[1] por día.

Rara vez veo esto discutido, y creo que eso es triste. Sospecho que las cifras son mucho peores para los marcos populares, como Firefox y las aplicaciones web interactivas de lujo, y sería interesante investigarlas.

^{[1] Lo inventé, 10 millones de segundos por 50 vatios. La cifra exacta depende de muchas cosas.}

A veces, solo tienes algoritmos que no pueden ser mejores que el tiempo lineal para los que todavía hay una fuerte demanda de rendimiento.

Un ejemplo es el procesamiento de video donde no se puede hacer que una imagen / cuadro sea más brillante como un ejemplo básico sin recorrer cada píxel (bueno, supongo que puede hacerlo con algún tipo de estructura jerárquica que indique las propiedades heredadas por los niños que finalmente descienden en mosaicos de imagen para nodos de hoja, pero luego diferiría un mayor costo de bucle a través de cada píxel al renderizador y el código probablemente sería más difícil de mantener que incluso el filtro de imagen más micro optimizado).

Hay muchos casos así en mi campo. Tiendo a hacer bucles de complejidad más lineal que tienen que tocar todo o leer todo lo que se beneficia de cualquier tipo de algoritmo o estructura de datos sofisticada. No hay trabajo que se pueda omitir cuando hay que tocar todo. Por lo tanto, en ese momento, si inevitablemente se trata de una complejidad lineal, debe hacer que el trabajo realizado por iteración sea más barato y más barato.

Entonces, en mi caso, las optimizaciones más importantes y comunes son a menudo representaciones de datos y diseños de memoria, subprocesos múltiples y SIMD (normalmente en este orden, siendo la representación de datos la más importante, ya que afecta la capacidad de hacer las dos últimas). No estoy teniendo tantos problemas que se resuelvan con árboles, tablas hash, algoritmos de clasificación y cosas de ese tipo. Mi código diario está más en la vena de, "para cada cosa, hacer algo".

Por supuesto, es otro caso para hablar sobre cuándo son necesarias las optimizaciones (y, lo que es más importante, cuando no lo son), micro o algorítmica. Pero en mi caso particular, si una ruta de ejecución crítica necesita optimización, las ganancias de velocidad 10x + a menudo se logran mediante optimizaciones de micro-nivel como multihilo, SIMD y reorganización de diseños de memoria y patrones de acceso para mejorar la localidad de referencia. No es tan frecuente que pueda, digamos, reemplazar un tipo de burbuja con un introsort o un tipo de radix o una detección de colisión de complejidad cuadrática con un BVH, tanto como encontrar puntos de acceso que, por ejemplo, se benefician de la división en campo frío / caliente. p>

Ahora, en mi caso, mi campo es tan crítico para el rendimiento (ráfaga de rayos, motores de física, etc.) que un rayo de rayos lento pero perfectamente correcto que demora 10 horas en renderizar una imagen a menudo se considera inútil o más rápido que uno completamente interactivo, pero produce las imágenes más feas con rayos que se filtran por todas partes debido a la falta de intersección de rayos / tri impermeable. Podría decirse que la velocidad es la principal medida de calidad de dicho software, incluso más que la corrección hasta cierto punto (ya que "corrección" es una idea difusa con el trazado de rayos ya que todo se aproxima, siempre que no se bloquee o algo así). Y cuando ese es el caso, si no pienso en la eficiencia por adelantado, tengo que cambiar el código en el nivel de diseño más caro para manejar diseños más eficientes. Entonces, si no pienso suficientemente en la eficiencia al momento de diseñar algo como un trazador de rayos o un motor de física, es probable que tenga que volver a escribir todo el maldito asunto antes de que pueda ser considerado lo suficientemente útil en producción y por los usuarios reales, no por los ingenieros.

El juego es otro campo similar al mío. No importa qué tan correcta sea la lógica de tu juego o qué tan fácil de mantener y brillante esté tu código base si tu juego se ejecuta a 1 cuadro por segundo como una presentación de diapositivas. En ciertos campos, la falta de velocidad podría inutilizar la aplicación a sus usuarios. A diferencia de los juegos, no hay una métrica "suficientemente buena" en áreas como el trazado de rayos. Los usuarios siempre quieren más velocidad, y la competencia industrial es predominantemente en la búsqueda de soluciones más rápidas. Nunca será lo suficientemente bueno hasta que sea en tiempo real, momento en el cual los juegos usarán trazadores de ruta. Y es probable que aún no sea lo suficientemente bueno para VFX, ya que los artistas podrían querer cargar miles de millones de polígonos y realizar simulaciones de partículas con autocolisión entre miles de millones de partículas a más de 30 FPS.

Ahora, si es de alguna comodidad, a pesar de eso, todavía escribo alrededor del 90% del código en un lenguaje de scripting (Lua) sin ninguna preocupación sobre el rendimiento en absoluto. Pero tengo una cantidad inusualmente grande de código que realmente necesita recorrer millones a miles de millones de cosas, y cuando lo haces de millones a miles de millones de cosas, empiezas a notar una diferencia épica entre el código ingenuo de un solo hilo que invoca una falla de caché con cada iteración frente a, digamos, un vector vectorizado que se ejecuta en paralelo y accede a bloques contiguos donde no se cargan datos irrelevantes en una línea de caché.

Como mencionó, preocuparse por los problemas de micro desempeño no vale la pena antes de tener en cuenta algunos problemas realmente causados por estos problemas

Es realmente imposible responder esta pregunta en general. La mayoría del software que se está construyendo hoy en día son sitios web internos y aplicaciones de LOB, y para ese tipo de programación su razonamiento es bastante correcto. Por otro lado, si está escribiendo algo como un controlador de dispositivo o un motor de juego, ninguna optimización es "prematura"; es probable que su software se ejecute en sistemas muy diferentes con diferentes restricciones de hardware. En ese caso, debe diseñar para el rendimiento y asegurarse de no elegir un algoritmo subóptimo.

Creo que el problema del programador, que se preocupa tanto por el rendimiento, es que a veces en su vida necesitaba escribir un código de microempresas, tal vez con mucha urgencia, y aprendió, aprendió, aprendió y al final Sabía muchas cosas y trucos.

Y ahora es difícil de olvidar, y sin una medición previa, lo que demuestra que no tiene que preocuparse, está en el lado seguro, usando código rápido.

Siempre es bueno mostrar su conocimiento profundo, sus habilidades y algunos trucos, y reutilizar algo que ha aprendido. Te hace sentir valioso, y el tiempo, gastarlo en aprender, valiendo la pena.

A veces en mi vida, aprendí que el incremento de prefijo es más rápido ...

for (int i = 0; i < MAX; ++i)

... que el incremento postfix:

for (int i = 0; i < MAX; i++)

Ahora, si MAX es bajo, no importará, y si hay trabajo real en el bucle, tampoco importará. Pero no hay una razón para usar la versión postfix, incluso si el compilador de hoy optimiza el código por su cuenta.

Tal vez los buscadores de rendimiento necesitan un objetivo adicional, además de escribir 'código de trabajo', como 'código de trabajo y legible' para tener una guía en el gran mar de opciones.

  

¿He tenido la suerte de no tener que preocuparme demasiado por ello o soy un mal programador?

¿Te interesan tus necesidades? Si el rendimiento no es un requisito, entonces no te preocupes. Pasar un tiempo significativo en ello es un perjuicio para su empleador.

Hasta cierto punto, el rendimiento es siempre un requisito. Si puede golpearlo sin pensarlo, está justificado que no lo piense.

Personalmente, la mayoría de las veces me siento impulsado por el rendimiento cuando mis pruebas tardan mucho en aprobarse. Estoy demasiado impaciente para esperar 5 minutos mientras pasan una serie de pruebas. Pero eso generalmente se resuelve jugando con las pruebas.

  

Mi pregunta es ¿por qué a un gran número de programadores les importa tanto? ¿Es realmente un problema para la mayoría de los desarrolladores,

Hay un gran número de programadores que están justificados en cuanto a lo que les importa. Hay grandes números que no lo son. Vamos a hablar de los que no lo son.

Una de las primeras cosas que los programadores aprenden en la escuela, después de cómo hacer que las cosas realmente funcionen, es la gran notación O. Muchos de ellos aprenden la lección correctamente y, por lo tanto, se enfocan adecuadamente en las cosas impactadas dramáticamente por n. Otros no obtienen los cálculos y solo eliminan la lección que, una vez que funciona, debe ser rápida. Peor aún, algunos de estos estudiantes nunca aprenden nada más sobre lo que es importante hacer con su código, además de hacerlo funcionar y hacerlo funcionar rápidamente. Las lecciones perdidas: hágalo legible, diseñe bien, no juegue en él sin ninguna razón.

Knuth tenía razón: la optimización prematura es la raíz de todo mal. Pero una vez que funciona, ¿cuál es el siguiente paso? Rápido ¿verdad? ¡NO! El siguiente paso es legible. Legible es el primer, el siguiente, el medio y el último paso. Muchas de las personas que encuentro que hacen optimizaciones de rendimiento innecesarias están generando facilidad de lectura bajo el bus.

Algunos incluso sienten una emoción perversa por lo ilegible que es su código. Han tenido que sufrir viendo códigos difíciles de entender creados por otros, por lo que ahora es su turno de pagar.

Lo sé porque solía hacer esto. Una vez refactoré una línea 5 perfectamente legible si la estructura se redujo a una expresión booleana indescifrable de una línea y la envié orgullosamente a mi profesor esperando impresionar, ya que podía crear algo tan compacto e intimidante. No recibí los elogios que esperaba.

Si el código permanece legible, hacerlo rápido después es fácil. Es por eso que Knuth enfatiza "prematuro" no "innecesario". Porque claro, más rápido es mejor. Pero mejor solo es mejor dependiendo de lo que sacrifiques por ello. Así que espere hasta que sepa qué rendimiento realmente necesita antes de sacrificarse por él. Sacrificar la legibilidad de mala gana porque una vez que se ha ido, es difícil regresar.

Más allá de la legibilidad está el mundo entero del diseño de software. De qué trata este sitio. Algunos no tienen ni idea de qué hacer en cuanto al diseño. Entonces, como no pueden impresionar con el diseño, crean un desorden indescifrable para que la gente no pueda decir que no tienen ni idea. Dado que nadie corrige su código, debe ser un buen código, ¿no?

Para algunos, el rendimiento es la única excusa para hacer lo que quieran. Los programadores tienen mucho poder y autonomía. La confianza se ha puesto en ellos. No abuses de la confianza.