[gull] [EXTERNAL] grep et barre de progression

[Félix Hauri]

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  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch