Je suis assez content de vous proposer ma nouvelle version: 0.1.0!!
https://f-hauri.ch/vrac/ppGrep.sh.txt
Le problème vient de ce que le script est utile quand tout est à lire...
lorsque tout est en cache, alors cela peut aller très (trop) vite, alors
certain process démarrent au moment où d'autres terminent, bref mon script
perd (parfois) le fil...
Du coup, ma nouvelle version re-lance l'entier du process, mais sans
paralellisation, ce qui ne prend que peu de temps puisque tout est
en cache...
Le résultat est:
- jusqu'à ~1 seconde de plus :-(
- 2 lignes de plus dans le terminal
- mais une sortie complête et correcte dans STDOUT.
- le script devient utilisable au quotidien.
Test: Je fais "grep -l vt100 /var/lib/dpkg/info/*.list", sur la sortie,
je fait un "wc" et un "sha1sum" afin de comparer facilement les résultats:
$ sync;sudo tee /proc/sys/vm/drop_caches <<<3
3
$ time { /tmp/ppGrep.sh vt100 /var/lib/dpkg/info/*.list | tee >(sha1sum) >(wc
) >/dev/null ;}|cat
mmdebstrap.list
0.00%
xxd.list
0.00%
0.00%
Proc run: 0, done: 10. Files:
2281/2281██████████████████████████████████100.00%
54 54 3884
d32f817ca090304fa48691bf7c73470408ec30f8 -
real 0m8.442s
user 0m1.619s
sys 0m2.834s
Premier run: 8,4 secondes!
$ sync;sudo tee /proc/sys/vm/drop_caches <<<3
3
$ time { grep vt100 /var/lib/dpkg/info/*.list | tee >(sha1sum) >(wc
) >/dev/null ;}|cat
54 54 3884
d32f817ca090304fa48691bf7c73470408ec30f8 -
real 0m11.947s
user 0m0.036s
sys 0m0.137s
Premier run, avec grep: 11,9 secondes!!
Lorsqu'il faut parcourir le fs et lire les fichier, alors la parallelisation
est utile!!
Par contre, lorsque tout est en cache:
$ time { /tmp/ppGrep.sh vt100 /var/lib/dpkg/info/*.list | tee >(sha1sum) >(wc
) >/dev/null ;}|cat
Proc run: 0, done: 10. Files:
2281/2281██████████████████████████████████100.00%
54 54 3884
d32f817ca090304fa48691bf7c73470408ec30f8 -
real 0m0.322s
user 0m0.106s
sys 0m0.077s
Second run, tout est en cache: 0.32 secondes
$ time { grep vt100 /var/lib/dpkg/info/*.list | tee >(sha1sum) >(wc
) >/dev/null ;}|cat
54 54 3884
d32f817ca090304fa48691bf7c73470408ec30f8 -
real 0m0.040s
user 0m0.023s
sys 0m0.019s
Second run, tout est en cache, avec grep: 0.04 secondes.
$ time { /tmp/ppGrep.sh vt100 /var/lib/dpkg/info/*.list | tee >(sha1sum) >(wc
) >/dev/null ;}|cat
WARNING: Kill 3709312!
Ouptut may be inaccurate! (loosed: 0000 -> 1/10)
Rerun w/o parallelization!
Proc run: 0, done: 4. Files:
2281/2281██████████████████████████████████100.00%
54 54 3884
d32f817ca090304fa48691bf7c73470408ec30f8 -
real 0m1.042s
user 0m0.704s
sys 0m0.358s
Second run, tout est en cache, mais ``race condition'' -> rerun -> 1.04 secondes
Mais le résultat est constant:
3884 octets, sha1: d32f817ca090304fa48691bf7c73470408ec30f8
Et pour les ``grep'' plus importants, tels que ne pouvant tenir en cache,
alors la parallelisation est systématiquement efficace.
Le Fri, Jan 03, 2025 at 03:48:07PM +0100, Félix Hauri via gull a écrit :
> Cela fonctionne bien, tant qu'il y a du temps qui se passe pour chaque
> grep... Si tout est en cache et que les sous-process terminent en
> même temps, on peut perdre des fins de process (``wait -p''):
>
> En relançant la même commande alors que tout est en cache mémoire,
> j'obtiens facilement:
>
> $ ppGrep.sh -sl vt100 /var/lib/dpkg/info/*.list
> WARNING: Kill 2138039!
> Ouptut may be inaccurate!
--
Félix Hauri - <fe...@f-hauri.ch> - http://www.f-hauri.ch
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
