Rapidez de inicio de programas y otros

[Horst von Brand]

rodrigo ahumada montenegro <rodahummont en yahoo.com.ar> wrote:

[...]

> ...recién iniciado, entro a mi sesion en kde (bien pesado, debe haber botado 
> varias cosas de la RAM), abro un terminal y escribo: ls /usr/bin
> 1 mississippi 2 mississippi 3 mississippi 4 mississippi 5 mississippi y 
> aparece el resultado. 

> time dice 
> real    0m3.892s
> user    0m0.028s
> sys     0m0.072s
> 
> ovbiamente la segunda vez es casi instantáneo:
> real    0m0.155s
> user    0m0.040s
> sys     0m0.036s
> 
> /usr/bin 1938 elementos
> y
> /usr/lib/ 1661 elementos.

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.

> asi que supongo que cargar un programa por primera vez debe demorar en el
> peor caso 10 mississippis

Supongo es tu medida de tiempo, +/- 1[s]?

>                           (1 por buscar el ejecutable en /usr/bin

Jamas tanto (salvo que tengas un i386/25 y diskette...)

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

>                                                        (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_.

> [...]

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

> también cada programa instala sus dll en su propio directorio en archivos de 
> prog., entonces al momento de enlazar las dll no se daría el problema de 
> arriba de demorarse casi 4 seg. buscando en /usr/lib...

En ambos casos tiene que ubicar el archivo del caso en el directorio... y
/no/ se comparte en RAM.
-- 
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