Barrapunto

No estarás intentando compilar una bomba atómica en casa, ¿verdad?

Al igual que ocurre con el resto de cosas, si algo deja de (o simplemente aparenta) ser un bien escaso (como ocurre ahora en el primer mundo con la electricidad, agua, comida...) pasa a ocupar un segundo plano y centramos los esfuerzos en otro tema.

Hace unos años durante la revolución multimedia si que dedicaban muchos esfuerzos a ahorrar memoria y optimizarla lo mejor posible, al igual que pasaba con el acceso a disco, recuerdo las competiciones que existían entre programas de formateo de disquetes en el menor tiempo posible, o el uso de 'duplicadores de capacidad de disco'.

Donde supongo que si que habrá conciencia de la memoria es en los dispositivos móviles, pero para ordenadores de sobremesa no creo que los desarrolladores le dediquen demasiado tiempo a la búsqueda de estructuras de datos que metan en dos bytes el año, para que luego en el 2000 se vaya todo al garete.

Concretamente un PIII a 733Mz, con varios discos duros (vete tu a saber por qué), aunque eso sí, con pantalla a 1024x768.

Lo que si le he puesto es memoria: Creo que tengo en total 192 megas (64 + 128). Tengo la swap con como mímino 89 megas usados, y habitualmente ciento y tantos.

Y he de darte parcialmente la razón: Uso un KDE (lo que haya en debian testing), y la cosa, si bien no es para tirar cohetes, tampoco es lenta. Eso sí, lo tengo peladillo, sin una sola alegría visual de esas que parece que están de moda. Bueno, excepto cuando arranco el OO.org (de uso obligado para mí), y lo dejo abandonado, porque como me lo mande a la swap la cagamos, eso si que va lento, hasta recuperarlo.

Bueno, a lo que iba, hace relativamente poco, leí en una revista un comentario acerca de distribuciones linux en las que se echaba en cara precisamente esto, que se recomienda un mínimo de 512 Mb de RAM, cuando antiguamente una de los puntos fuertes era que corría en hardware viejo con soltura. Como carezco de opinión propia y no tengo dineros para comprar hardware nuevo, le daré la razón a ese artículo: Por favor, software ligero, integrado en el escritorio, y eficiente. Y a ser posible, que no use Java, por dios, hasta al Mac de casa le pesa!.

Sin duda esto ocurre porque hoy día se prima poco una programación eficiente, pero muchas veces es por culpa de como se hacen las cosas al principio, como es la elección incorrecta del lenguaje de programación y las librerías a usar (más cuando son gráficas) según la amplitud y para que se va a usar el programa, la engorrosa programación monolítica (a veces por flojera), mala o inexistente documentación y poco comentado, código sucio, poco optimizado, etc. Todo esto, y más cosas que me dejo en el tintero, al principio no se nota cuando el programa tiene unos cientos de lineas de código, pero si cuando programa creciendo versión a versión, llegará un momento que la criatura se ha convertido en una gran bestia devoradora de memoria a la que nadie tendrá valor para intentar reescribirla de cero y bien, claro, funcionará, pero a costa de una voracidad casi insaciable de recursos.

Es cierto lo que antes han dicho de que ahora la memoria no es un bien "escaso" (lo que no implica que todo el mundo se lo pueda permitir), pero yo lo veo una excusa fácil para no hacer bien las cosas, ya que hoy día se prima la programación rápida más que la programación eficiente, en resumen "la cosa es que funcione, no importa como". A varios programadores de hace algunas décadas se les llamaban hackers porque exprimían y aprovechaban los pocos bytes de memoria que tenían en las máquinas, misma solución con el mínimo uso de recursos, y esto, salvo para unos cuantos programadores (como los "demomakers" y programadores de la vieja escuela), ya parece cosa del pasado lo que no debería ser así.

Por suerte, como bien ha apuntado Rei, en el mundo del software libre esos programadores no son una especie extinta, y para Linux o *BSD hay aplicaciones hechas con la intención de ser lo más livianas posibles usando óptimamente los recursos disponibles y realizando la mismas tareas que otro análogo y más grande.

Antes para hacer una aplicación mas o menos decente tenias que hacerla en C por ejemplo, a un nivel bajo, haciendo free's, malloc's ....

Ahora la haces en C# o ne JAVA en la mitad de tiempo.

Y esta premisa se esta aplicando en todos los aspectos. En la programación PDA simplemente no sale rentable hacerte tu programa empresarial en C y si en eVB o usando el CompacFrameWork porque la velocidad a la que se ejecute simplemente no importa, si en el hardware va mas o menos bien. Siempre hay partes criticas (como el nucleo de un sistema operativo) que por lógica, se busca eficiencia a toda costa y se hace en C, pero porque simplemente, si no lo haces tu, lo hara la competencia y no venderas ni uno.

Otro caso ya aparte creo yo es en como escojan los algoritmos para hacer una determinada tarea.

Si lo puedes hacer de orden n2, porque hacerlo de orden 10n. Pero, al menos lo que he visto yo, en muy pocas ocasiones un programador con trabajos tipicos se enfrentara a un problema de dichas caracteristicas, y si se enfrenta y lo hace mal, entonces es que es incompetente, lo haga en C o lo haga en JAVA, o en lo que le de la gana.

Aun asi para los amantes de la optimizacion, siempre quedan las aplicaciones 3d donde el tiempo de respuesta es critico, simplemente porque no hay hardware de bajo coste que te ahorre los costes de no hacerlo critico.

Si no, fijaos en las aplicaciones 2d para los moviles (java). HAce años, impensable hacerlos con una maquina virtual, hoy en dia, todos los juegos se hacen en java.

Habló un usuario con Gnome 2.8.2 en un PII 533 y 192 MB RAM sin ningún problema. Eso si con gentoo y prelink...

Otra cosa ¿Como has medido la memoria que "gastan"? Que yo sepa no se puede ya que Linux (otra vez el kernel) se expande hasta ocupar toda la memoria aunque no la use, como un gas en un recipiente.