¿Es una optimización prematura para desarrollar en máquinas lentas?

Question

Debemos desarrollar en slow boxen porque nos obliga a optimizar al principio.

Randall Hyde señala en The Fallacy of Premature Optimization, hay un montón de ideas falsas de todo el presupuesto Hoare:

Debemos olvidarnos de pequeñas eficiencias, dicen que alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal

En particular, aunque hoy en día las máquinas gritan en comparación con las de la época de Hoare, eso no significa que deba "evitarse la optimización". Entonces, ¿mi colega respetado tiene un punto cuando sugiere que debemos desarrollar en cajas de tempo modesto? La idea es que los cuellos de botella de rendimiento son más irritantes en una caja lenta y por lo tanto es probable que reciban atención.

Answer 1

Las computadoras lentas no lo ayudarán a encontrar sus problemas de rendimiento.

Si los datos de prueba son solo unos pocos cientos de filas en una tabla, su base de datos lo almacenará en la memoria caché y nunca encontrará consultas mal escritas o un diseño incorrecto de tabla/índice. Si su aplicación de servidor no es un servidor multiproceso, no lo encontrará hasta que lo pruebe con 500 usuarios. O si la aplicación embotella el ancho de banda.

La optimización es "Una buena cosa", pero como les digo a los nuevos desarrolladores que tienen todo tipo de ideas sobre cómo hacerlo mejor "No me importa qué tan rápido me den la respuesta incorrecta". Hazlo bien primero, luego hazlo más rápido cuando encuentres un cuello de botella. Un programador experimentado va a diseñarlo y construirlo razonablemente bien para empezar.

Si el rendimiento es realmente crítico (¿transacciones en milisegundos en tiempo real?), Entonces necesita diseñar e implementar un conjunto de puntos de referencia y herramientas para demostrar científicamente que sus cambios lo están haciendo más rápido. Hay demasiadas variables que afectan el rendimiento.

Además, existe la excusa clásica del programador que sacarán a relucir, 'pero está funcionando lento porque deliberadamente hemos elegido computadoras lentas, funcionará mucho más rápido cuando lo implementemos'.

Si su colega piensa que es importante darle un equipo lento y lo puso a cargo de 'rendimiento' :-)

Answer 2

Esto debería ser wiki comunitario, ya que es bastante subjetivo y no hay una respuesta "correcta".

Dicho esto, debe desarrollar en la máquina más rápida disponible para usted. Sí, cualquier cosa más lenta introducirá irritación y lo alentará a corregir las ralentizaciones, pero solo a un precio muy alto:

Su productividad como programador está directamente relacionada con la cantidad de cosas que puede guardar en la cabeza, y cualquier cosa que ralentiza su proceso o le impide en absoluto alarga la cantidad de tiempo que tiene para mantener esas ideas en memoria a corto plazo, lo que lo hace más propenso a olvidarlas, y tiene que volver a aprenderlas.

Esperar a que un programa se compile permite que la pila de errores, posibles problemas y correcciones desaparezcan de su cabeza al distraerse. Esperar a que se cargue un cuadro de diálogo o terminar una consulta para interrumpirlo de manera similar.

Incluso si ignora ese efecto, todavía tiene la verdad de la afirmación posterior: la optimización anticipada lo dejará persiguiéndose en círculos, rompiendo el código que ya funciona y adivinando (con frecuencia con poca precisión) dónde las cosas pueden atascarse. En primer lugar, diseñe su código correctamente, y puede olvidarse de la optimización hasta que haya tenido la oportunidad de conformarse con un poco, momento en el que cualquier optimización necesaria será obvia.

Answer 3

Depende de su tiempo de entrega. Si está en un ciclo de entrega de 12 meses, entonces debe desarrollar en una caja con una velocidad decente ya que los 12 meses de sus clientes tendrán mejores cajas "promedio" que el "promedio" actual.

A medida que su ciclo de desarrollo se acerca "hoy", sus máquinas de desarrollo deben acercarse a la velocidad "promedio" actual de las cajas de sus clientes.

Answer 4

Supongo que dependerá de lo que esté haciendo y de la audiencia prevista.

Si está escribiendo software para hardware fijo (por ejemplo, juegos de consola), utilice equipos (al menos equipos de prueba) que sean similares o iguales a los que desplegará.

Si está desarrollando aplicaciones de escritorio o algo en ese ámbito, desarrolle en la máquina que desee y luego sintonícela para ejecutar en el hardware min-spec deseado. Del mismo modo, si está desarrollando un software interno, es probable que haya una mínima especificación para las máquinas que la empresa desea comprar. En ese caso, desarrolle en una máquina rápida (para disminuir el tiempo de desarrollo y, por lo tanto, los costos) y pruebe en contra de esa mínima especificación.

En pocas palabras, desarrolle en la máquina más rápida que pueda tener en sus manos, y pruebe el hardware mínimo o exacto que va a soportar.

Answer 5

Normalmente desarrollo en la máquina más rápida que puedo tener en mis manos.

La mayoría de las veces estoy ejecutando una compilación de depuración, que ya es bastante lenta.

Answer 6

por el amor de Codd, utilizar herramientas de perfilado, no máquinas de desarrollo lento!

Answer 7

La optimización debe evitarse, ¿no nos dio eso Vista? : p

Pero con toda seriedad, siempre es una cuestión de concesiones. Preguntas importantes para hacerse a sí mismo

¿Qué plataforma usarán sus usuarios finales? ¿Puedo dejar caer los ciclos? ¿Qué pasará si lo hago?

Estoy de acuerdo con la mayoría de que el desarrollo inicial debe hacerse en la máquina más rápida o eficiente (no necesariamente la misma) disponible para usted. Pero para ejecutar pruebas, ejecútelo en su plataforma de destino y realice pruebas a menudo y temprano.

Answer 8

Si está programando hardware que está cerca de los entornos finales de prueba y producción, tiende a descubrir que hay menos sorpresas desagradables a la hora de lanzar el código.

He visto a bastantes programadores ser golpeados de lado por problemas serios, pero inesperados causados ​​por sus máquinas que son mucho más rápidas que la mayoría de sus usuarios. Pero también, he visto el mismo problema con los datos. El código se prueba en un pequeño conjunto de datos y luego se "desmorona" en uno grande.

Cualquier diferencia en los entornos de desarrollo e implementación puede ser la fuente de problemas inesperados.

Aún así, dado que la programación es costosa y consume mucho tiempo, si el usuario final ejecuta un equipo lento y desactualizado, la mejor solución es lidiar con él en el momento de la prueba (y programar algunas pruebas iniciales para verificar la usabilidad y el tiempo).

¿Por qué lisiar a sus programadores solo porque le preocupa perder un posible problema? Esa no es una estrategia de desarrollo sensata.

Paul.

Answer 9

Creo que es un concepto de sonido (pero tal vez porque funciona para mí).

Si mi estación de trabajo de desarrollador es demasiado rápida, creo que no creo que las ideas lo hagan lo suficiente simplemente porque hay poco tiempo de penalización para volver a generar la imagen del software o descargarla al objetivo. Diría que al menos la mitad de mis descargas fueron innecesarias porque solo recordé algo que me perdí justo antes de depurar el código.

La máquina de destino podría contener un procesador acelerado. Si, en una MCU incrustada, tienes la mitad de FLASH, RAM y ciclos de reloj por segundo, los desarrolladores serán mucho más cuidadosos al diseñar su código. Una vez sugerí variables de bytes para las longitudes de los registros individuales en un área de datos (no en RAM sino en un eeprom serial) y recibí la respuesta "no necesitamos ser mezquinos". Unos meses más tarde alcanzan el techo RAM (128KiB). Mi reflexión era que para esta aplicación nunca habría ningún registro de más de 256 bytes simplemente porque no había memoria RAM para copiarlos.

Para aplicaciones de servidor, creo que sería una gran idea tener un hardware (mucho) de menor rendimiento para probar. Dos o cuatro núcleos en lugar de dieciséis (o más). 1.6 GHz istdo 2.8. La lista continua. Por lo general, un servidor (debido al hecho de que todos le hablan) es un cuello de botella en la arquitectura del sistema. Y eso es mucho antes de que comience a desarrollar la aplicación (servidor) para ello.