Patrick Lamaizière <adresse@est.invalid> wrote:
> Michel Talon :
>
> [...]
>
> > mais dans un
> > temps tout à fait comparable, et non pas en y passant des heures comme
> > fait portupgrade.
>
> Ben je ne pige pas trop, ton script devrait être plus rapide que
> portsdb -U pour construire l'index ?

Tu as vu les commentaires qui sont au début de mon script? Ils recoupent
exactement ce que tu vois, sachant que portsdb -U fait tourner make
index. Sur ma machine, make index va plus vite que le script, comme je
le dis. J'ai passé des jours et des jours à essayer de comprendre
pourquoi, sans succés. J'ai écrit plusieurs variantes du script:

- une utilise de l'IO asynchrone et select() pour choisir le pipe qui a
des données. Je me suis aperçu que le parallélisme produit était
faible.
- l'autre, celle que tu as, utilise des threads pour multiplexer les
créations d'index. Elle a un trés bon parallélisme, mais aussi
évidemment de l'overhead.
- une troisième copie exactement ce que fait "make index" sauf les
appels à perl. C'est à dire que je vais par exemple dans
"accessibility" et je fais essentiellement "make -j 3 describe"
exactement comme le fait FreeBSD, en écrivant le résultat des
invocations de make dans un fichier séparé pour chaque port, puis en
relisant et "parsant" ces fichiers. Je m'étais dit, que, aprés tout,
bien que make -j3 utilise des fork() à la place des threads, c'était
peut être plus efficace. Je me suis dit que peut être make restant dans
le cache c'était plus rapide. Par contre il faut tout le temps aller
écrire dans /tmp ce qui est plus lent. J'ai aussi essayé une version en
sortant les résultats des make dans des pipe.

Or, a ma grande surprise, les 3 programmes très différents tournent
exactement dans le même temps, et plus lentement que "make index" qui est
à priori beaucoup plus merdique à cause des 16000 invocations de perl.
La différence ne peut pas être attribuèe à une lenteur éventuelle de
python, car elle est plus grande que le temps total de fonctionnement de
python! Elle est entièrement due à un mauvais agencement des "make"
simultanés.

J'ai même découvert des choses encore plus surprenantes. J'ai écrit 2
petits scripts qui reproduisent ce que fait make index:
niobe% cat essai1_timing.py
#!/usr/local/bin/python
#essai timing
import time, os
tstart = time.time()
os.system("cd /usr/ports/multimedia && make describe")
print time.time() - tstart
# resultat 21.4909200668

niobe% cat essai2_timing.py
#!/usr/local/bin/python
#essai timing
import time, os
tstart = time.time()
os.system('''cd /usr/ports/multimedia && make -B \
-j 2 INDEX_TMPDIR=/tmp/toto BUILDING_INDEX=1 \
PORTSTOP=1 describe ''')
print time.time() - tstart
# resultat 42.0145590305

Le deuxième reproduit *exactement* ou alors je n'ai rien compris, ce que
fait "make index" en mode parallèle. Comme tu peux voir, le benchmark
est désastreux. A titre de comparaison, mes scripts mettent 24s. sur
ce même "multimedia". Note que le simple "make describe" non parallèle
est de loin ce qui donne les meilleurs résultats!

Bref je suis arrivé à la conclusion que je n'y comprenais rien, ou que
tous ces effets sont dus au scheduler complètement défectueux de
FreeBSD, et je suis passé à autre chose ... De toute façon le but de ce
script est rééllement de parser les ports correspondant aux paquets
installés, ce qui prend de l'ordre de 1mn, on n'est pas à 10s. prés.

En ce moment j'écris un petit serveur http qui montre ce que
montreraient les README.html si on les fabriquait.


>
> # /usr/bin/time -h portsdb -U
> Updating the ports index ... Generating INDEX.tmp - please
> 21m37,03s real 16m4,14s user 3m21,52s sys
>
> # /usr/bin/time -h ./build_index.py
> ......accessibility......
> Total time spent: 26 minutes 27 seconds.
> You will find the generated index in INDEX and the errors
> encountered in ErrorLog.
> 26m28,23s real 18m0,15s user 6m48,05s sys
>

--

Michel TALON