Rapidez de inicio de programas y otros [Was: Re: OT: linux en pc antiguos (era: distro para revivir celeron de 400 con 24 de ram)]

[Horst von Brand]

rodrigo ahumada montenegro <rodahummont en yahoo.com.ar> wrote:
> a propósito de este tema,

Nada tiene que ver con el tema, si se comienza una nueva discusion sirvanse
hacerlo con un nuevo mensaje y un nuevo titulo.

>                           en un foro vi una pregunta sobre por que programas
> como firefox o openoffice parten mas rápido en windows que en linux y yo
> pensé en algunas posibles causas de esto...

... en algunos casos es porque Windows hace trampa, y muestra la interfaz
grafica antes que el programa haya terminado de inicializarse, en otras
porque en Windows una buena parte de lo que es "el programa" en Linux es
parte del sistema operativo, que siempre esta cargado en memoria...

> (antes que todo, esto se refiere a la carga "en frío" del programa, osea,
> la de primera vez, está claro que las segundas cargas de un programas son
> bien rápidas por que esta todavía en RAM, además creo que es lo que mas
> influye en la percepción de que "el sistema es lento")

Algo de eso hay. Y esta el ubicar, cargar en memoria y enlazar las
bibliotecas compartidas (algunos programas tienen cientos de estas).

> 1.- no tengo experiencia con otros sistemas de archivos, sólo fat32 ntfs y
> ext3 y he notado que ext3 parece que es lenta al momento de listar el
> contenido de un directorio por primera vez (incluso se puede sentir, aqui
> cuando uso un programa para manejar archivos y toco por ejemplo /usr/bin
> o /usr/lib, se siente cuando uno los toca por primera vez por que el programa
> se toma una pausa antes de mostrar los contenidos. A todo esto en una página
> se hablaba de recomendaciones para acelerar la partida  de kde, y una de esas
> era hacer un script "preloadkde", el cual se ejecuta al partir kdm, en
> segundo plano, y lo que hace es simplemente un find de directorios
> como /usr/bin y /usr/lib (osea lista el contenido y fuerza a cargar la lista
> de archivos en la RAM).

Si no dices con que comparas... y que tanto se demora el programa GUIistico
del caso en mostrar iconitos etc no es buena medida del rendimiento del
sistema de archivos, recuerdese que Windows usa la "genial" idea de que la
"extension" indica que es lo que el archivo contiene... Unix debe mirar
dentro, no basta el nombre. Y si la cascara grafica del caso es torpe,
demas la mayor parte de la demora es culpa de ella (bueno, incluso en caso
que no lo sea).

> 2.- una de las cosas que noté cuando recién empecé a usar linux es la
> gran cantidad de cosas que hay en /usr, la gran cantidad de código
> compartido que tienen los programas, y que los programas son de tamaño
> pequeño. (esto es comparando con windows (no conozco otros sistemas),
> donde los programas por lo general son grandes, monolíticos (todo en
> uno), usan pocas (creo) dll compartidas (y en general se comparten
> siempre las mismas, el resto son dll propias o el programa esta enlazado
> estáticamente)).

Exacto. Uno de los graves problemas con Win es precisamente que todo el
mundo y su abuelita arrastra /sus/ versiones de cuanta DLL existe, para
evitar que por versiones diferentes el programa falle.

> entonces

> 	1.- si uno tiene que acomodar linux en un pc antiguo con un disco duro
>  lento, ¿no convendría usar otro sistema de archivos en vez de ext3? (que
>  conste que esto es solo percepción mía)

No. Si, los hay mas rapidos; pero la robustez de ext3 frente a imprevistos
como cortes de energia (p.ej. ReiserFS es mas rapido, y usa menos
espacio...  hasta que se corta la luz y no queda mas que reformatear) y el
hecho que sea lejos el sistema de archivos mas usado (y por tanto, probado;
ReiserFS ya no se mantiene realmente) bien vale un poquito de rendimiento.
Y las diferencias no son nunca tan grandes, recuerdese que un disco es
/muy/ lento frente a RAM, si el rendimiento va mal probablemente ganas mas
poniendo RAM extra que con otra cosa. Y tambien ayuda separar entre
controladoras IDE, que son capaces de manejar un dispositivo a la vez (o
sea, disco y CD en controladoras diferentes si se puede; disco de programas
y disco de swap/datos en la otra, ...).

> 	2.- ya se que al usar mas código compartido se puede ahorrar en uso
> memoria (páginas de código), pero para programas grandes como firefox ¿no
> convendría que sean mas monolíticos y usen menos bibliotecas compartidas?

Si Firefox usa las mismas bibliotecas que otros programas graficos que usas
junto con el, te conviene que sean compartidas (== menos uso neto de RAM,
menos datos que cargar del disco, ...).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513