Rapidez de inicio de programas y otros

Horst von Brand vonbrand en inf.utfsm.cl
Jue Mar 2 17:09:45 CLST 2006


rodrigo ahumada montenegro <rodahummont en yahoo.com.ar> wrote:
> El Mié 01 Mar 2006 20:06, Horst von Brand escribió:
> 
> [...]
> >
> > Raro. Aca es 2,2s vs 1,9s, o sea nunca tanta diferencia (demas se explica
> > por otras actividades en este cacharro). Y sospecho que es mas que nada el
> > tiempo escribir la lista de nombres el culpable...
> >
> > Yep, "ls /usr/bin > /dev/null" se demora 0,1s.

> si, despues de enviar, me di cuenta también, ls sobre un elemento de
> /usr/bin es mas rápido que listar todos...

;-)

[...]

> > >                                                                   y otra
> > > por enlazar la primera lib.so buscandola en /usr/lib...

> > Podria ser, si es una biblioteca inmensa de la que se usan muchos simbolos.
> > No es el caso aca... ldd(1) te da el detalle de las bibliotecas a que un
> > ejecutable hace referencia, en este caso mas que nada piezas de glibc.

> mmm... sí, firefox-bin: 38, todas vienen de /usr/lib y /lib excepto 5 que
> son exclusivas de firefox. no son muy grandes ( a lo mas unos 700k)

Que esten o no en /lib y /usr/lib no hace mayor diferencia, lo que importa
al final es si ya estan en RAM (otros la usan).

> si fuera por la cantidad de simbolos a enlazar, ¿no debería demorar
> aprox. lo mismo en la primera y siguientes cargadas?

No, porque en la 2a seguramente ya hay partes del cuento en RAM.

> de todas formas  ya me di cuenta que ext3 no tiene la culpa.

Bien!

> > >                                                        (y a esto agregar
> > > que muchas son enlaces simbolicos...))

> > No hace mayor diferencia.

> > > (aquĆ­ soy ignorante: cuando se enlaza una biblioteca de nombre $X,
> > > forzosamente debe ejecutarse un "ls /usr/lib" y despuƩs se averigua si
> > > la biblioteca ya estaba en RAM, o la biblioteca en RAM guarda su nombre
> > > $X para evitar el tener que listar /usr/lib y contar hasta el quinto
> > > mississippi?)

> > Se mmap(2)ea la biblioteca (el archivo) a RAM, y el sistema de memoria
> > virtual se da cuenta que ya esta, solito y sin ayuda. Es precisamente el
> > mecanismo que se usa para que sean bibliotecas _compartidas_.

> para identificar que es el mismo archivo, ¿usa la ruta (string) o el
> número de bloque de disco?

El numero del inodo, o sea ninguna de las anteriores ;-)

[La identidad del archivo en ese sistema de archivos, para quienes no
conocen la terminologia]

> (de primera supongo que el número de bloque para ser independiente del
> sistema de archivos, pero ¿qué pasaría con nfs?...)

Ver arriba...
-- 
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


Más información sobre la lista de distribución Linux