Re: [HS] lignes uniques, performances
Fri, 26 Mar 2004 15:00:33 +0000, Yves Rutschle a écrit :
> On Fri, Mar 26, 2004 at 02:47:13PM +0100, Sylvain Sauvage wrote:
> > Pas tout à fait : dans un tube, il y a deux bouts.
>
> Qui sont comptés en temps système...
>
> > 'time cat linux | perl ...' mesure le temps que met cat pour lire ET
> > pour donner les infos à perl. Pas forcément celui que met perl pour
> > lire ce qui vient de cat (preuve : le temps est différent avec
> > <linux). Le tube est un buffer qui modifie le comportement de cat ET
> > celui de perl.
>
> Non, le tube ne modifie que le temps système et `time cat
> linux | perl` mesure le temps de l'ensemble, pas du tout
> simplement cat. L'execution de cat (en temps user) est bien
> évidement très courte:
>
> [yves@oban]:yves$ (time cat linux ) | perl -ne 'print if !$l{$_}++' >
> /dev/null
>
> real 1m4.090s
> user 0m0.030s
> sys 0m1.620s
C'est presque exactement ce que je disais : il mesure le temps de cat ET
du tube (ou plutôt ce que je voulais dire, comme on peut le comprendre
avec la « preuve » que je donne, et comme on ne le comprend pas avec la
phrase que j'ai écrite). Mais le tube introduit un buffer et des E/S qui
ne sont pas gérés par perl ou awk. Cela modifie donc leur comportement.
> Le temps système depend d'autres choses (buffers et swap
> par exemple) et le temps réel a évidement peu de rapports
> avec notre problème.
>
> > De plus, comme le disait Manu <kolter@free.fr>, il faut
> > faire attention aux buffers du système. Et je pense qu'il
> > faudrait même ignorer la première (lorsque le noyau lit le
> > fichier pour la première fois). Une autre solution est
> > d'avoir un fichier qui soit deux ou trois fois plus gros
> > que la mémoire disponible : ça éliminerait le cache de
> > linux.
>
> Tout ça ne change pas le temps *user* qui est le seul à être
> à peu près prédictible. Qq soit la charge, il devrait
> rester le même, même si tu swappes le process, même si tu le
> fais tourner sur un portable que tu endors pendant 45 jours
> avant de le reveiller pour finir.
Je crois qu'il ne faut pas oublier ici que ce qui nous intéresse c'est le
traitement de fichiers et donc des E/S. Or le temps user ne donne que le
temps processeur, pas celui des attentes d'E/S (qui change beaucoup avec
la charge).
> Et donc, avec des charges CPU de plus en plus grosses:
>
> [yves@oban]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
>
> real 5m1.439s
> user 0m24.810s
> sys 0m5.030s
> [yves@oban]:yves$ time perl -ne 'print if !$l{$_}++' < linux > /dev/null
>
> real 11m1.316s
> user 0m25.720s
> sys 0m21.720s
>
> Les temps users restent essentiellement les mêmes. Dans le
> second cas, le temps système est soudainement plus grand car
> linux a commencé à swapper (perl monte à plus de 270Mo).
Normal : le travail est toujours le même, que ce soit en perl ou en awk
(un test aléatoire dans un gros tableau).
Ce qui différencie les deux, c'est la gestion de la mémoire et des E/S.
Il est donc logique que toutes les infos de time nous intéresse (y compris
le %w).
> >Il faut lancer chaque commande au moins trois ou
> > quatre fois (une centaine pour faire de *vrais*
> > statistiques).
>
> Je suis d'accord avec ça, et je dois avouer par rapport à
> mon premier mail que la différence entre cat | perl et perl
> < fichier se perd dans le bruit de mesure. Ça montre tout de
> même que le UUOC n'est finalement pas particulièrement
> horrible.
Surtout s'il ne sert qu'une seule fois.
--
| Sylvain Sauvage, docteur [IAD & SMA] | bzz ? .o:.
| GREYC -- CNRS UMR 6072, Université de Caen | ` % ^..^___§ o::o::
| tél://+33 (0)2 31 56 74 31 | @ (oo) ) ::o::o
|__ http://www.info.unicaen.fr/~sauvage _______| _____`|'___WW¯WW_____][__
Reply to: