Luego nos preocupamos por que el código hiciera lo que tenía que hacer, resultó ser el mismo engendro pero compilando y funcionando correctamente... Seguramente quienes no tomaron el camino del desarrollo hasta aquí llegaron. Sin embargo, quienes optamos por procesar el café para convertirlo en código seguimos avanzando, prontamente aprendimos mejores prácticas de programación, cómo nombrar adecuadamente nuestras variables, algunos frameworks que facilitaron nuestra vida y de repente nuestro trabajo drásticamente artístico pasó a hacer toda una pieza de ingeniería de software, cuyo diseño y funcionamiento impecable quizá contrastaban contra la poca documentación... ¡Pero es que ese código habla por sí mismo! No necesita más documentación.
Finalmente nos enseñaron algo de eficiencia, no lo explicaron en términos de "Complejidad algorítmica" y lo entendimos como "Si está lento, necesitas un mejor PC". Y así fue como toda una teoría de la computación pasó a segundo plano. Hoy no es raro encontrarnos con código productivo cuyos algoritmos están hechos, digamos, "A lo maldita sea", quizá por el empeño de dar una solución rápida a los proyectos, falta de experticia o quizá por nuestra falta de imaginación y no pensar un poco más allá.
Pero ¿Por qué es importante la eficiencia? Quizá debí empezar por aquí, pues un software diseñado con buenas prácticas y los mejores algoritmos no necesariamente sea el más rápido para procesar una acción, sino el que mejor administra los recursos que tiene para hacerlo... ¿Y qué es administrar mejor los recursos? ¿Es usar toda la RAM? ¡Para eso está! ¿Usar toda la CPU? ¡Para eso Intel/AMD lo construyó así! ¿Será acaso usar todo el disco duro? Pues para eso compramos discos ya en terminos de terabytes.
La respuesta es depende porque cada sistema y el negocio que está soportando tiene sus particularidades... Pero vayamos a un software que per se está poco o nulo optimizado ¿Qué pasaría si lo mejoramos en pro de la eficiencia? Mi respuesta es una teoría tan inquietante como sorprendente: ¡Podría salvar el mundo!. Tener código estructurado eficientemente necesariamente tendría un impacto positivo en el uso de los recursos, como comenté antes, esto no quiere decir que el usuario vea que ahora funciona más rápido aunque puede que sí, sino que reduciríamos, por ejemplo, la carga de uso media de CPU, quizá también liberemos algo memoria y por lo pronto también, quizá nos ahorremos un par de llamadas extras a los discos duros.
"Source Code" es una película por allá de 2011, no tiene nada que ver con el post pero me pareció graciosa la imagen para ambientar mi teoría.
¿Y cómo eso podría salvar el mundo? Bueno, alguna vez notaste que al exigir tu PC o portátil ¿Este se calienta más? Esto sucede porque de la misma forma, requiere más energía para responder a tus exigencias... Así las cosas, el primer paradigma a quitarnos de la mente es que sí se puede ahorrar energía eléctrica aún cuando el servidor esté encendido toda la noche. En Internet hay varias herramientas que puedes usar para calcular el uso de energía de un equipo de cómputo en ciertas circustancias. Para soportar mi teoría, encontré un interesante estudio de la Universidad de Pensilvania en el que tenemos el consumo en watts de varios equipos de cómputo sometidos a prueba:
| Make & Model | Basic Specifications | Off (plugged in) | Boot (peak) | Moderate Use (range) | Quiescent (5 minutes of no activity) | Sleep |
|
Apple iMac/Intel 21.5-inch (purchased late 2012) |
Core i5, 8.0 GB RAM, 1.0 TB hard drive, OS X 10.8.2 (clean) |
1 | 60 | 52-56 |
44 (18 w/ LCD in sleep) |
1 |
|
Apple iMac/Intel 21.5-inch (purchased late 2011) |
Core i5, 4.0 GB RAM, 500 GB hard drive, OS X 10.7.4 (clean) |
1 |
105 |
92-96 |
88 (38 w/ LCD in sleep) |
1 |
|
Apple iMac/Intel 27-inch (purchased late 2009) |
Core i5, 4.0 GB RAM, 1.0 TB hard drive, OS X 10.7.4 (clean) |
1 | 177 | 141-147 |
130 (73 w/ LCD in sleep) |
1 |
|
Apple iMac/Intel 24-inch (purchased early 2009) |
Core 2 Duo, 4.0 GB RAM, 640 GB hard drive, OS X 10.6.2 (clean) |
1 | 141 | 146-154 |
88 (42 w/ LCD in sleep) |
1 |
|
Dell Optiplex 9010 All-in-One 23-inch (purchased late 2012) |
Core i7, 8.0 GB RAM, 500 GB hard drive, Windows 8 Pro (clean) |
1 | 61 | 43-45 | 43-44 | 1 |
|
Dell Optiplex 9010 w/ Dell LCD (purchased mid 2012) |
Core i7, 8.0 GB RAM, Windows 7 Ultimate (clean) |
1 | 48 | 66 | 20-22 | 1 |
|
Dell Optiplex 990 w/ Dell LCD (purchased mid 2011) |
Core i7, 8.0 GB RAM, Windows 7 Professional (clean) |
1 | 86 | 33-37 | 28 | 1 |
|
Dell Optiplex 980 w/ Dell LCD (purchased mid 2010) |
Core i7, 4.0 GB RAM, Windows 7 Professional (clean) |
1 | 66 | 64-71 | 46-61 | 1 |
|
Dell Optiplex 780 w/ Dell LCD (purchased late 2009) |
Core 2 Duo, 4.0 GB RAM, Windows 7 Professional (clean) |
2 | 108 | not tested | not tested | 1 |
|
Dell Optiplex 760 w/ 19-inch Dell LCD (purchased late 2008) |
Core 2 Duo, 2.0 GB RAM, 160 GB/7200 RPM hard drive, UltraSharp 1907FPV display, Windows 7 Ultimate (clean) |
1 | 116 | 95-111 |
81-83 (50-52 w/ LCD off) |
1 |
|
Lenovo ThinkCentre M91 w/ Lenovo LCD (purchased early 2012) |
Core i7, 8.0 GB RAM, Windows 7 Professional (clean) |
1 | 88 | 50-68 | 40 | 1 |
Computer Power Usage
https://secure.www.upenn.edu/computing/resources/category/hardware/article/computer-power-usage
Como podemos notar, un computador exigido al máximo está consumiendo hasta 40% más energía (Dependiendo del modelo) que el mismo equipo en un uso calificado como moderado. Claro, si hablamos de optimizar un algoritmo que se lleva el 100% de la CPU para que solo lo haga 60% no es una tarea fácil (Empezando porque en lo primero que pensaríamos es en comprar un nuevo servidor de acuerdo a nuestros fundamentos en optimización de algoritmos que mencioné antes), aunque he de decir también, que he visto casos en los que en verdad, hay soluciones supremamente sencillas para evitar esos picos de uso de hardware sin sacrificar considerablemente el estado del algoritmo.
Pero eso es un mundo ideal de unicornios y hadas madrinas, seamos incrédulos, supongamos que solo optimizamos con dificultad nada más que un 10% (...) Vienen entonces las siguientes preguntas a mi teoría ¿No se ahorrarán unos pocos watts al año? ¿Y si nuestro sistema corre sobre varios servidores?, ¿Por varios años?... Pues mi percepción es que en el estado en que tenemos a nuestro planeta, cada watt ahorrado, por ínfimo que parezca cuenta. La diferencia es la que haríamos todos si codificamos con la eficiencia en mente.
¿Cómo optimizar nuestro código para salvar al mundo?
Mi recomendación básica, es ser muy aplicado con las buenas prácticas de programación, esto incluye:
- Usar los tipos de datos adecuados para nuestra aplicación. Ej. no usar integer si voy a guardar solo 1 y 0, en ese caso usar boolean ahorraría algo de memoria.
- Analizar detenidamente las consultas a fuentes de datos de tal forma que solo se cargue la información necesaria y haciendo uso de las facultades del motor (Caché, llaves primarias, por ejemplo).
- Arquitecta tu aplicación, diseños modulares y funciones centralizadas permitirán enfocarte mejor en la solución y eventuales inconvenientes de rendimiento.
- Utiliza herramientas de análisis estático de código. Por ejemplo, en Java utilizo Sonar, que da muy buenos tips acerca de la codificación del software.
- Reduce al mínimo el nivel de verbosidad de logs de la aplicación y auditoría.
- Mientras tu software está en producción ¡Mide su rendimiento!
- Y más importante, nunca dejes de pensar en cómo podrías hacer tu software mejor.
