Quelques test sur la rapidité de commandes equivalentes

Hizoka · Le 16/11/2009, à 23:37

Voici quelques test qui permettent de prendre conscience de la grande différence de rapidité en fonction des commandes utilisées...

Tests fait maisons hein, rien d'extraordinaire non plus...

Découpe d'une variable a écrit :

Code juste en bash pur :

for (( a=1; a < 10000; a++ ))
do
variable="caca.boudin.prout.ouesh"
variable2=${variable#*.}
variable3=${variable2#*.}
echo "${variable3}" > /dev/null
done
times

0m0.610s 0m0.030s
0m0.000s 0m0.000s

PS : Est-il possible de regroupé en une commande les differentes variables ?

Code avec cut et echo :

for (( a=1; a < 10000; a++ ))
do
variable="caca.boudin.prout.ouesh"
variable2=$(echo "$variable" | cut -d"." -f2)
echo "${variable3}" > /dev/null
done
times 

0m1.040s 0m1.270s
0m7.530s 0m13.460s

Code avec cut et <<< :

for (( a=1; a < 10000; a++ ))
do
variable="caca.boudin.prout.ouesh"
variable2=$(cut -d"." -f2 <<< "$variable")
echo "${variable3}" > /dev/null
done
times 

0m0.980s 0m1.500s
0m7.540s 0m11.930s

Affichage d'une ligne particuliaire a écrit :

Code avec uniquement sed :

echo "$(ls -1 /home/hizoka/)" > /tmp/test.txt

for (( a=1; a < 10000; a++ ))
do
sed -n "4p" /tmp/test.txt
done
times

0m0.630s 0m1.230s
0m6.900s 0m7.740s

Code avec cat et grep :

echo "$(ls -1 /home/hizoka/)" > /tmp/test.txt

for (( a=1; a < 10000; a++ ))
do
cat /tmp/test.txt | grep -n "" | grep "^4:"
done
times

0m0.450s 0m2.580s
0m20.340s 0m23.580s

Code avec head et tail :

echo "$(ls -1 /home/hizoka/)" > /tmp/test.txt

for (( a=1; a < 10000; a++ ))
do
head -4 /tmp/test.txt | tail -1
done
times

0m0.400s 0m2.070s
0m13.240s 0m15.390s

Recherche d'une ligne avec modification a écrit :

Code avec sed uniquement :

echo "Voici une ligne 1
Voila une ligne 2
Et voici une ligne 3
Et puis une ligne 4" > /tmp/test.txt

for (( a=1; a < 10000; a++ ))
do
sed -n "/puis/ s/ligne/cacahouete/p" /tmp/test.txt
done
times

0m0.520s 0m1.120s
0m6.690s 0m8.100s

Code avec grep et sed :

echo "Voici une ligne 1
Voila une ligne 2
Et voici une ligne 3
Et puis une ligne 4" > /tmp/test.txt

for (( a=1; a < 10000; a++ ))
do
grep "puis" /tmp/test.txt | sed " s/ligne/cacahouete/" 
done
times

0m0.440s 0m2.340s
0m12.990s 0m16.510s

Code avec grep et bash :

echo "Voici une ligne 1
Voila une ligne 2
Et voici une ligne 3
Et puis une ligne 4" > /tmp/test.txt

for (( a=1; a < 10000; a++ ))
do
var=$(grep "puis" /tmp/test.txt)
echo "${var/ligne/cacahouete}"
done
times

0m0.810s 0m1.190s
0m7.280s 0m8.600s

Si vous avez d'autres tests intéressant ou des commandes équivalentes à celles proposées, donnez les

Dernière modification par Hizoka (Le 25/06/2010, à 04:13)

Hawkmoon · Le 17/11/2009, à 13:44

Tu as beaucoup de temps libre, à ce que je vois...

Hizoka · Le 17/11/2009, à 21:30

en même temps ça m'a pas pris beaucoup de temps...

de plus ça m'a permis de modifier certains scripts un peu longuets, du coup je fais tourner l'infos, si ça intéresse personne, tant pis

PS : tu sembles en avoir aussi vu que tu m'as (peut être lu) et que tu as répondu

Hizoka · Le 01/12/2009, à 23:40

un autre exemple entre un sed et que du bash : http://forum.ubuntu-fr.org/viewtopic.php?pid=3110320#p3110320

Totor · Le 02/12/2009, à 11:59

il me semblait bien que tu avais lancé un topic à ce sujet.
De façon générale, ce qui peut être fait en full bash est plus rapide que d'utiliser des outils externes. En fait, c'est logique, l'utilisation de awk, sed, grep ... demande la création de processus, réservation de ressources, libération des ressources / processus ce qui est donc du temps en plus. On le voit bien dans mon exemple : le full bash utilise beaucoup moins de ressources système !

Hizoka · Le 02/12/2009, à 18:34

totor, toi qui sait beaucoup de chose, c'est quoi la diff entre base fichier.sh et exec fichier.sh ?

n3o51 · Le 02/12/2009, à 19:37

bonsoir
tu le sort de ou le base ? je connais pas

base fichier.sh et exec fichier.sh

Dernière modification par n3o51 (Le 02/12/2009, à 19:37)

Totor · Le 02/12/2009, à 21:27

Hizoka a écrit :

totor, toi qui sait beaucoup de chose

c vite dit !

Hizoka a écrit :

, c'est quoi la diff entre base fichier.sh et exec fichier.sh ?

je ne connais pas l'instruction base ...

pour ce qui est d'exec, cela permet de remplacer le processus qui utilise exec par le script/instruction/programme lancé par exec.
Cela veut donc dire que toutes les instructions qui suivent exec command ne seront jamais exécutées.

Hizoka · Le 03/12/2009, à 08:31

c'est une erreur c'est pas base mais bash

d'accord, donc faut eviter de le lancer si on d'autres commandes apres

donc je conserve bash.

n3o51 · Le 03/12/2009, à 17:34

Quel dommage ça aurait fait une commande que Totor connaisse pas xD

Hizoka · Le 25/06/2010, à 04:12

Je re sur ce topic avec pour test, une suite de cut ou une modification de l'IFS avec creation de liste.

Alors oui, on connait deja la plus rapide mais c'est marrant de voir la différence :

for i in {1..100}
do
	track="1@gtk-no|audio-x-generic|2|Version Originale|A_MPEG/L3|eng"

	# Sauvegarde de l'ancien IFS, Modification de l'IFS
	old_ifs=${IFS}
	IFS='|'

	# Création de la liste contenant les infos de la piste, Séparation des infos
	liste=(${track})
	icone=${liste[1]}
	id=${liste[2]}
	info=${liste[3]}
	codec=${liste[4]}
	langue=${liste[5]}

	# Rétablissement de l'ancien IFS
	IFS=${old_ifs}

	echo "gtk-no|${icone}|${ID}|${info:-Inconnu}|${codec}|${langue:-Inconnue}"
done

La commande time renvoie : real 0m0.019s

for i in {1..100}
do
	track="1@gtk-no|audio-x-generic|2|Version Originale|A_MPEG/L3|eng"

	# Création de la liste contenant les infos de la piste, Séparation des infos
	icone=$(cut -d"|" -f1 <<< "${track}")
	id=$(cut -d"|" -f2 <<< "${track}")
	info=$(cut -d"|" -f3 <<< "${track}")
	codec=$(cut -d"|" -f4 <<< "${track}")
	langue=$(cut -d"|" -f5 <<< "${track}")

	echo "gtk-no|${icone}|${ID}|${info:-Inconnu}|${codec}|${langue:-Inconnue}"
done

La commande time renvoie : real 0m1.092s

Soit une petite différence... les cut prennent 100x plus de temps

Totor · Le 25/06/2010, à 08:43

Hizoka a écrit :

Je re sur ce topic avec pour test, une suite de cut ou une modification de l'IFS avec creation de liste.
Alors oui, on connait deja la plus rapide mais c'est marrant de voir la différence :
[...]
	# Sauvegarde de l'ancien IFS, Modification de l'IFS
	old_ifs=${IFS}
	IFS='|'

	# Création de la liste contenant les infos de la piste, Séparation des infos
	liste=(${track})
	icone=${liste[1]}
	id=${liste[2]}
	info=${liste[3]}
	codec=${liste[4]}
	langue=${liste[5]}

	# Rétablissement de l'ancien IFS
	IFS=${old_ifs}
[...]

Il n'est pas utile de sauvegarder l'IFS en utilisant la syntaxe variable=valeur commande
Ainsi, la variable n'est définie que dans le cadre d'exécution de la commande.

On obtient donc :

[...]
        # Création de la liste contenant les infos de la piste, Séparation des infos
	IFS='|' liste=(${track})
	icone=${liste[1]}
	id=${liste[2]}
	info=${liste[3]}
	codec=${liste[4]}
	langue=${liste[5]}
[...]

Hizoka a écrit :

Soit une petite différence... les cut prennent 100x plus de temps

Pour moi, ça fait 57,5 x plus rapide

Postmortem · Le 25/06/2010, à 13:49

Bonjour à tous,
une petite question, dans la ligne ci-dessous :

IFS='|' liste=(${track})

La variable IFS est donc prise en compte seulement pour liste=(${track}) et remise à sa valeur par défaut après, c'est bien ça ??
Je pensais donc que toto=azerty echo $toto me renverrais azerty... Mais non !!

$ toto=azerty echo $toto

$ bash --version
GNU bash, version 3.1.17(1)-release (x86_64-suse-linux)
Copyright (C) 2005 Free Software Foundation, Inc.

C'est normal que ça ne fonctionne pas avec une commande ??

Hizoka · Le 25/06/2010, à 15:37

Pour moi, ça fait 57,5 x plus rapide

oups, j'ai fait ça a la louche.

même question que Postmortem pour :
IFS='|' liste=(${track})

même dans un script ?

Watael · Le 25/06/2010, à 17:16

non, il faut sauvegarder et restaurer IFS

$ track="foo|bar|baz"
$ IFS='|' list=( $track )
$ printf '%s\n' "${list[@]}"
foo
bar
baz
$ echo "$IFS"
|

on peut assigner plusieurs variables sur la même ligne sans point-virgule, ce sans qu'elles interfèrent entres elles.
Mais

$ track="foo|bar|baz"
$ IFS="|" read -a list <<<"$track"
$ echo "${IFS}."

.

ici IFS devient une variable d'environnement uniquement pour la commande read, tout comme LC_ALL=C man man, pour avoir les pages de man en anglais.

pour le deuxième point soulevé par Postmortem, la Substitution des paramètres s'effectue avant l'affectation.

Dernière modification par Watael (Le 25/06/2010, à 21:08)

Totor · Le 26/06/2010, à 09:10

Watael a écrit :

non, il faut sauvegarder et restaurer IFS

Je suis trés étonné car avant de poster, j'ai vérifié sur un solaris avec un bash dont je n'ai plus en tête la version mais qui date mais d'origine et ça fonctionnait.
De même, à la lecture de ta réponse, j'ai de nouveau vérifié mais cette fois-ci en bash 4.1.5 et ça fonctionne également.

Watael · Le 26/06/2010, à 10:34

bonjour Totor

ah? c'est étrange
Si ça ne te dérange pas, peux-tu nous copier le code que tu utilises s'il est diffèrent de celui qui est plus haut ?

Note, que je ne dis pas que ça ne fonctionne pas, je dis que la valeur originale de l'IFS n'est pas restaurée quand on tape le code directement dans la console.

Postmortem · Le 26/06/2010, à 11:07

Merci à tous, j'ai encore appris des trucs sympas sur ce fil !
J'ai testé et chez moi, ça fonctionne comme le dit Watael, du moins directement dans une console.
Si j'ai bien tout compris le man bash :
IFS='|' list=( $track ) : ce ne sont que des affectations donc les variables sont prises en compte dans l'environnement courant.
IFS="|" read -a list <<<"$track" : une affectation puis une commande donc la variable est variable d'environnement seulement pour la commande read et n'est pas prise en compte dans l'environnement courant.

Dernière modification par Postmortem (Le 26/06/2010, à 11:08)

Hizoka · Le 26/06/2010, à 17:08

idem que watael en faisant :

track="1@gtk-no|audio-x-generic|2|Version Originale|A_MPEG/L3|eng"
IFS='|' liste=(${track})
icone=${liste[1]}
id=${liste[2]}
info=${liste[3]}
codec=${liste[4]}
langue=${liste[5]}
echo "gtk-no|${icone}|${ID}|${info:-Inconnu}|${codec}|${langue:-Inconnue}"
echo "$IFS"

mais c'est vrai que ça peut être interressant.

Totor · Le 28/06/2010, à 09:10

Bonjour,

Alors un retour de ma part :
1ère chose : j'ai à nouveau testé sur mon Solaris 5.8 Generic_117350-08 sun4u sparc SUNW,Sun-Fire-V490.
A première vue : pas besoin de sauvegarder l'IFS
version du bash : BASH_VERSINFO=([0]="2" [1]="03" [2]="0" [3]="1" [4]="release" [5]="sparc-sun-solaris")

Mon code :

#tracks="a|b|c|d"
# echo ${IFS}

# IFS="|" tab=( ${tracks} )
# echo ${IFS}

# printf "%s\n" ${tab[@]}
a
b
c
d

--> le tableau est bien constitué et l'IFS semble conservé ! Et oui "semble" car si je change la méthode d'affichage de l'IFS ... stupeur ...

#echo "${IFS}"
|

Je n'ai pas le temps de me pencher sur le sujet mais ... ça me turlupine

Hizoka · Le 28/06/2010, à 15:36

ouais ! un truc que Totor ne connaissait pas !!!

Mais c 'est vrai que c'est étrange...

Hizoka · Le 21/07/2010, à 12:35

for i in {1..100}
do
du -s Zenitor | sed 's/\t.*//'
done
=> real    0m0.203s

Va de 0.180 a 0.210s

for i in {1..100}
do
du -s Zenitor | awk '{print $1}'
done
=> real    0m0.202s

environ 0.210s...

for i in {1..100}
do
test=($(du -s Zenitor))
done
=> real    0m0.198s

environ 0.200s

for i in {1..100}
do
df -P  | grep "sdb6" | awk '{print $4}'
done
=> real    0m0.176s

environ 0.180s

for i in {1..100}
do
df -P | awk '/sdb6/ {print $4}'
done
=> real    0m0.212s

environ 0.200s...

Dernière modification par Hizoka (Le 21/07/2010, à 12:47)

nesthib · Le 22/07/2010, à 08:47

au lieu de faire ton df à chaque fois tu devrais enregistrer le résultat dans une variable, à mon avis c'est cette étape qui limite et cela fausse ton résultat

idem pour le test #3 tu ne produis pas d'affichage ce qui est beaucoup plus économe (perso je redirige toujours vers /dev/null pour mes tests de rapidité)

Hizoka · Le 22/07/2010, à 20:27

en effet, je les referais en suivant tes conseils !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 16/11/2009, à 23:37

Quelques test sur la rapidité de commandes equivalentes

#2 Le 17/11/2009, à 13:44

Re : Quelques test sur la rapidité de commandes equivalentes

#3 Le 17/11/2009, à 21:30

Re : Quelques test sur la rapidité de commandes equivalentes

#4 Le 01/12/2009, à 23:40

Re : Quelques test sur la rapidité de commandes equivalentes

#5 Le 02/12/2009, à 11:59

Re : Quelques test sur la rapidité de commandes equivalentes

#6 Le 02/12/2009, à 18:34

Re : Quelques test sur la rapidité de commandes equivalentes

#7 Le 02/12/2009, à 19:37

Re : Quelques test sur la rapidité de commandes equivalentes

#8 Le 02/12/2009, à 21:27

Re : Quelques test sur la rapidité de commandes equivalentes

#9 Le 03/12/2009, à 08:31

Re : Quelques test sur la rapidité de commandes equivalentes

#10 Le 03/12/2009, à 17:34

Re : Quelques test sur la rapidité de commandes equivalentes

#11 Le 25/06/2010, à 04:12

Re : Quelques test sur la rapidité de commandes equivalentes

#12 Le 25/06/2010, à 08:43

Re : Quelques test sur la rapidité de commandes equivalentes

#13 Le 25/06/2010, à 13:49

Re : Quelques test sur la rapidité de commandes equivalentes

#14 Le 25/06/2010, à 15:37

Re : Quelques test sur la rapidité de commandes equivalentes

#15 Le 25/06/2010, à 17:16

Re : Quelques test sur la rapidité de commandes equivalentes

#16 Le 26/06/2010, à 09:10

Re : Quelques test sur la rapidité de commandes equivalentes

#17 Le 26/06/2010, à 10:34

Re : Quelques test sur la rapidité de commandes equivalentes

#18 Le 26/06/2010, à 11:07

Re : Quelques test sur la rapidité de commandes equivalentes

#19 Le 26/06/2010, à 17:08

Re : Quelques test sur la rapidité de commandes equivalentes

#20 Le 28/06/2010, à 09:10

Re : Quelques test sur la rapidité de commandes equivalentes

#21 Le 28/06/2010, à 15:36

Re : Quelques test sur la rapidité de commandes equivalentes

#22 Le 21/07/2010, à 12:35

Re : Quelques test sur la rapidité de commandes equivalentes

#23 Le 22/07/2010, à 08:47

Re : Quelques test sur la rapidité de commandes equivalentes

#24 Le 22/07/2010, à 20:27

Re : Quelques test sur la rapidité de commandes equivalentes

Pied de page des forums