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)]

[Patricio Rojas O.]

Hola Listeros

Para la rapidez de inicio de programas y otros

On mar, 2006-02-28 at 15:25 -0300, Horst von Brand wrote:
> 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...
> 
Software PRELINK, CCACHE, DISTCC
Modificar los sysctl



> > (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, ...).

-- 
Patricio Rojas  
http://www.threboll.com          Servicios de Ingeniería en Informática