Comments on: ChangeLog/N+1

by: Ikitt

Sun, 29 Jul 2007 08:45:24 +0000

zef:
in effetti, almeno a primo acchito, non sconfinfera neanche me questo carico di moduli precaricati. Mi spiego meglio: se non altro per abitudine acquisita e` comodo, ma
sarebbe anche utile avere un modo carino per ridurlo al minimo, idealmente a zero,
e sono ragionevolmente convinto che un modo del genere ci sia.
Tornando ai moduli: in primis, sono ragionevolmente sicuro che una buona fetta di questi e` tirata su dalla configurazione del sito (/usr/lib/python$VERSION/site.py).
Rinominando brutalmente site.py si riduce il numero di open rispettivamente
a 24 e 145, che e` gia` meglio (occhio: prova fatta al volo e senza tanti crismi).
Noto poi che un discreto numero di moduli precaricati all’avvio riguarda configurazioni
di `locale’, roba tipo encodings e cose del genere, che IMHO ha senso mettere come moduli e non come builtin.
Inciso: sempre da prove al volo il numero di stat() e` parecchio alto, ma questo non e` una sorpresa dato il numero di open().

by: zefram

Sun, 29 Jul 2007 08:10:52 +0000

@Ikitt:

neanche io sono qui per fare il difensore del perl: ha tanti difetti, tra cui una VM con una memory footprint peggiore di python. ma, domanda: perché un interprete dovrebbe caricare un sacco di moduli di default?

ebassi@sprite:~$
strace -o /tmp/perl-foo perl -MFoo
Can’t locate Foo.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .).
BEGIN failed–compilation aborted.

numero di open:

ebassi@sprite:~$
grep open /tmp/perl-foo | grep ‘/usr/lib/’ | wc -l
27

di 35 totali. più una sessantina di stat(). questo perché perl non carica moduli di default. e le open sono tutte quante per determinare l’ambiente (locale, variabili, etc.).

by: Ikitt

Sun, 29 Jul 2007 07:00:13 +0000

Premessa 1: non sono qui per giocare all’avvocato difensore
Premessa 2: ho gia` detto che trovo orripilante il meccanismo per scrivere estensioni in C per py?

Per prima cosa ho pensato ai moduli caricati per default, ma poi mi son detto che non poteva essere quello il motivo del contendere, praticamente ogni ambiente “di scripting” (nomea impropria ma or non mi sovviene nulla di meglio) pre-carica un tot di roba (bash, tcl, sarei fortemente tentato di dire pure ruby e perl, ma sugli ultimi due non so/non rispondo).
Al che son passato a strace:
$ strace -o /tmp/py.log python -v -c ‘import foo’
$ grep open /tmp/py.log | grep foo | wc -l
56
Che si, son tantini, MA
1) ho installato un tot di moduli che allungano la lista di ricerca (PIL, pygtk, numeric…)
2) scorrendo a mano la lista non trovo nulla di evitabile, nel senso, si cerca
nei posti noti e nell’ordine noto, ordinatamente (prima estensioni poi moduli py e cosi` via)

Poi per curiosita`:
$ grep open /tmp/py.log | grep ‘/usr/lib’ | wc -l
205
Questo e` gia` piu` inquietante. Sarei curioso (per mero raffronto) di vedere cosa e come fa perl/ruby in merito in un caso paragonabile, perche` il mio intuito mi suggerisce che magari fa meglio, ma non stratosfericamente meglio.
Suggerimenti in merito? (chiedo perche` il mio amore verso perl e` circa uguale al tuo verso python, zef ;) )

by: zefram

Sun, 29 Jul 2007 05:18:10 +0000

@lawrence:

guarda la lista di accessi al disco quando carica tutti i moduli. e time non vale niente: prova sotto strace.

by: Lawrence Oluyede

Sat, 28 Jul 2007 23:36:15 +0000

Io non vedo nessun disco fisso volare eh:

python -v -c “import foo” 0.02s user 0.05s system 93% cpu 0.076 total

secondo me tu e Python avete cominciato con il piede sbagliato :D