Barrapunto

Un algoritmo funciona y ya!! el programador se va tan pancho a hacer otras labores, olvida optimizar y la respuesta es: compre mejor CPU y mas memoria.

Las generaciones de programadores pasadas que trabajaban con DOS y tenían esa limitante de los 640Kb o menos porque el DOS + Antivirus residente (TSR) dejaban menos de 500Kb haciamos maravillas optimizando cada registro, cada uso de variable y los programas eran de poco consumo y rápidos. Hoy veo programadores novatos que hacen programas devoradores de recursos e implementan herejías como:

1. Control de ciclos con variables tipo float o double (deben usar variables tipo int).

2. Uso del char en algunas variables (use fanáticamente int porque son nativas del procesador).

3. El manejo de estructuras de datos como arboles, listas, pilas, etc.. con las APIs mas abstractas y estratosféricas que encuentran con la pobre excusa de que así abstraen el problema cuando en realidad esconden el "ser tontos ignorantes que les da miedo usar directamente las estructuras". Obteniendo código muy lento.

4. Hiperabuso de funciones, he visto funciones que se usan solo una vez con dos líneas de código, ¿por que no la colocaron directamente en el grueso del código?

5. Funciones recursivas: el pecado original de la programación... ¿no saben que este tipo de programación consume demasiados recursos y es lenta?

6. Usar el lenguaje de moda o el que solo aprendieron en la Universidad sin importar que es mas lento que funcionario público.

7. La falsa autocomplacencia de "si señor cliente, el programa es muy lento pero es muy seguro, es poderoso, es flexible, es escalable, ..." y con las palabritas: "poderoso", "flexible", "escalable" disculpan un código mas lento que placa tectónica en movimiento.... y lo peor es que lo "poderoso", "flexible" y "escalable" jamás lo volverán a usar.

8. El "safe code" significa que "un hilo estará supervisando que el estúpido programador no haya cometido idioteces en manejo de punteros y manejo de memoria que bloqueen la aplicación avisándole donde cometió errores, pero este hilo y esa forma de protección traga recursos y hace el programa mas lento que la entrega de ayudas humanitarias en Africa", claro que suena mas guay "safe code".

9. No consultar practicas de optimización o mejorar el código en velocidad.

Pedíamos páginas XMS o reservábamos marcos de EMS. Después incluso poníamos la máquina en modo protegido y accediamos linealmente a la memoria.

Se deben usar punteros o iteradores pero en fin.

Tú eres de los que usan campos de bits para definir booleanos porque ocupan menos memoria que los int, ¿verdad? :-)

Las variables char ocupan en el código 4 bytes (o el tamaño de int) en el 99.999% de las plataformas por una cosa misteriosa llamada "alineamiento" :-). Algunos micros no leen direcciones que no estén alineadas al tamaño de int (que coincide con el ancho de registro) o del bus de datos. Otros, como x86, son lentos si no se hace.

Lo del mantenimiento y la reglilla de que el cuerpo de las funciones debe caber tabulado a 80 columnas en una pantalla también te es desconocido, igual que otra cosa que se llama inlining y que todos* los compiladores hacen.

Sobre todo en cpus con ventanas de registros :-P

El coste de mantener algo que es "poderoso", "flexible" y "escalable" pero lento es algo así como cien veces menor (en sueldos y horas de trabajo), con lo que te ahorras tienes de sobra para comprar más máquinas. Además algo "poderoso", "flexible" y "escalable" siempre se puede optimizar a posteriori mucho más fácil y barato que convertir algo "rápido" en "poderoso", "flexible" y "escalable". Otra regla que supongo que no te enseñaron es que las optimizaciones tempranas son malignas :-)

¿Conoces Ada?, ¿dejarías el control de una planta nuclear a un sistema que no tuviera esas salvaguardas?

Un problema real es que personas como tú creen que saben de lo que hablan y a lo mejor están incluso escribiendo código que se usa ahí fuera. No deseo a nadie que tenga que trabajar en algo escrito por ti.

¿Llamas hacer maravillas a meter un programa en 640 KiB? Entonces meterlos en menos de 64 KiB, por ejemplo en las máquinas con sistema operativo CP/M o en los Apple II debe de ser por lo menos un milagro o dos. Y no hablo ya de meterlos en un PIC de un puñadito de KiB, por limitar el tema a máquinas que se usaran para aplicaciones de gestión.

Tío, te has quedado obsoleto. Tanto al programador como al cliente lo que le interesa es la rapidez del desarrollo. Si un programa de gestión en .NET me ocupa, pongamos 80 MB de RAM y lo he hecho con cuatro clics en Visual Studio, ¿qué gano con hacerlo en C++ optimizando código y depurando si tardo 4 veces más para que ocupe sólo 10 MB de RAM? La industria mató a la artesanía hace mucho tiempo..

...que el que hizo la lista de la noticia.

El problema se llama estrechez de miras.

Ni todas las aplicaciones tienen que lidiar con bases de datos y conversiones de monedas o similares (como parece creer el autor de la lista original) ni todas las aplicaciones tienen como prioridad la optimización de la velocidad de ejecución (como su excelencia el Experto Experimentado sugiere).

Hay aplicaciones donde el tamaño del programa puede ser más importante que su velocidad (no siempre relacionados), o donde el tiempo de desarrollo es crítico, o donde la portabilidad es esencial...

Es más, incluso en campos donde la velocidad es muy importante, puede merecer la pena ir a más alto nivel. Un ejemplo: trabajo haciendo aplicaciones de cálculo científico. Las hacía en C siguiendo las reglas básicas de optimización como las que has mencionado. Ahora, en cambio, las escribo en Python y, aunque sigo optimizando de forma razonable, no pierdo mucho tiempo. Al final, son aplicaciones que se ejecutan menos de 10 veces antes de tener que modificarlas para incluir cosas nuevas... así que el tiempo de desarrollo es mucho más importante que el de ejecución.

¿Soy un inepto por hacerlo así? No. Conozco las alternativas y escojo la que mejor se adapta a cada situación concreta.

Anda, vete a programar un buscaminas en ensamblador, que mientras yo lo haré con PyQT.

5. Funciones recursivas: el pecado original de la programación... ¿no saben que este tipo de programación consume demasiados recursos y es lenta?

¿Sabes lo que es la recursividad terminal? Es cuando la llamada recursiva se encuentra en el último lugar de la función. Cualquier compilador para un lenguaje funcional es capaz de convertirlo en una iteración. Que los compiladores para lenguajes imperativos no le den importancia a la recursividad, y no sean capaces de aplicar una optimización tan vieja, no significa que la recursividad sea mala.