Une commande de terminal peut être 1000 fois plus rapide qu’une interface

Nicolas Furno |

Rob Griffiths est développeur et tous les mois, il récupère 25 rapports de ventes transmis par Apple pour ses logiciels vendus sur le Mac App Store. Ces rapports sont fournis sous une forme archivée (.gz) qu’il faut décompresser pour les exploiter. Précisons que ce sont des fichiers très légers, le plus lourd pèse 1 Ko et en moyenne, ces archives tournent autour de 300 ou 400 octets.

En passant par l’interface de macOS, donc par le Finder et par l’Utilitaire d’archive fourni avec le système, il faut compter environ 13 secondes pour extraire ces données sur son Mac. Même si ce n’est pas grand-chose en soi, c’est extrêmement lent pour décompresser des archives aussi légères. Et d’ailleurs, en passant par le terminal, l’opération sur le même Mac est terminée en 0,013 seconde. Soit environ mille fois plus rapidement, rien que ça !

Comment expliquer une telle différence ? Décompresser des archives aussi légères est une tâche tellement simple qu’elle est quasiment instantanée pour un ordinateur moderne. C’est d’ailleurs le cas avec le terminal : sitôt la commande saisie, l’opération est terminée.

Ce qui ralentit l’opération, c’est en fait l’interface. La vidéo le montre bien, l’utilitaire d’archive de macOS ouvre chaque fichier un par un, il l’affiche dans sa fenêtre, complète la barre de progression, retire l’élément, passe au suivant, etc. Et même s’il traite plusieurs fichiers en parallèle, cela reste une opération progressive où le temps nécessaire pour afficher les données surpasse largement le temps qu’il faut pour décompresser les fichiers à proprement parler.

Le terminal n’a pas à se soucier de l’interface et même s’il traite chaque fichier un par un, il va plus vite qu’en passant par le Finder. Il est si rapide que le gestionnaire de fichiers de macOS n’arrive pas à suivre : si vous regardez attentivement la vidéo, vous verrez que la tâche se termine avant que les fichiers soient affichés dans la fenêtre du Finder à côté.

Il faut plus longtemps pour afficher l’opération de décompression à l’écran que pour la mener à bien. Cliquer pour agrandir

C’est un cas un petit peu extrême qui pourrait facilement être corrigé si Apple le voulait. Par exemple, l’interface pourrait se contenter d’une seule barre de progression pour gagner du temps. D’autres utilitaires, comme The Unarchiver, s’en sortent d’ailleurs mieux que l’Utilitaire d’archive de macOS. Par ailleurs, la différence n’est aussi spectaculaire que dans ce cas précis, à savoir un grand nombre de petits fichiers compressés.

Si vous êtes dans le même cas que ce développeur que vous voulez gagner un petit peu de temps tous les mois, vous pouvez utiliser la commande de terminal sans passer par le terminal. Automator, Alfred, Keyboard Maestro… les solutions ne manquent pas et vous trouverez des explications à cette adresse.

avatar iPop | 

Et de plus le système calcul à chaque seconde toutes les ****peries qui traînent sur le bureau pour pouvoir les afficher.

avatar lll | 

L'impact est important en termes de RAM ?

avatar Nom d'utilisateur | 

Pour gagner encore plus de temps, utilisez Zsh et Oh-My-Zsh ???

De rien !

avatar C1rc3@0rc | 

Euh, ZSH est bien c'est certain, mais dans le cas présent que ce soit BASH, CSH, ou ZSH ça change rien. ZSH devient intéressant des que tu dois écrire un script de plus de 20 lignes et a ce moment faut passer a un vrai langage de script et de préférence a Python...

avatar Nom d'utilisateur | 

"ZSH devient intéressant des que tu dois écrire un script de plus de 20 lignes"

Whaaaaaaaatttt ??? ???

Enfin si tu l'utilise comme ça...

(Really? ? ya des gens qui code avec Zsh???)

avatar Nom d'utilisateur | 

Perso je l'utilise juste avec OMZ pour l'autocomplétion, les thèmes (Agnoster mon préféré ❤️), et les alias qui font gagner beaucoup de temps... et ça c'est juste génial?

avatar Un Type Vrai | 

:-)

avatar ssssteffff | 

*une application (graphique ou non) mal pensée / mal codée met 1000 fois plus de temps qu'une ligne de commande efficace.

Faire la même chose, fichier par fichier, avec barre de progression et tout pourrait voir les performances dégradées de manière considérable également.

avatar C1rc3@0rc | 

Meme bien codée, une application graphique subit l'impact de la lourdeur de l'interface graphique. De plus les UI actuelles sont pas du tout optimisées et se reposent massivement sur les performances graphique (compositing, animation, affichage) des processeurs graphiques... Si tu prends le meme logiciel d'il y a 10 et aujourd'hui, l'affichage est plus lent et moins reactif...

Ceci dit, The Unarchiver devrait etre livré avec MacOS, il est infiniment meilleur que le truc d'Apple.

avatar macinoe | 

Quand on fait plus de truc, ça prends plus de temps.

Whaouu c'etait une news signée Captain Obvious...

avatar Nicolas R. | 

J'étais en mode facepalm pendant la lecture. MacKevin découvre le terminal.

avatar whocancatchme | 

ahah tellement ça !

avatar caissonbulle | 

Dans le même ordre d'idée, compresser une grosse archive (fichiers et dossiers imbriqués multiples) avec BetterZip peut être très long... alors que cela peut prendre énormément moins de temps avec WinZip (que je recommande). En plus, j'ai eu de gros problème avec BetterZip qui ne "voyait" pas l'intégralité d'une archive... alors que WinZip voyait TOUS les fichiers. Je n'utilise plus BetterZip que pour sa capacité à compresser des petits fichiers (envois par mail par exemple) avec un simple raccourcis, sans avoir à lancer une quelconque application (en tâche de fond, sans interface envahissante).
.
Sinon, Keyboard Maestro est un utilitaire fantastique qui peut facilement remplacer une foultitude d'autres utilitaires : un MUST !... Et pour lancer des scripts de toutes sortes, il est parfait !...

avatar byte_order | 

> Le terminal n’a pas à se soucier de l’interface et même
> s’il traitait chaque fichier un par un (ce qui n’est pas le cas)

Ben si.

La commande "gzip -d -k *.gz" est résolue par le shell en "gzip -d -k 88071587_0716_AE.txt.gz 88071578_0716_AU.txt.gz .... etc" et l'application gzip ensuite fait la même opération de décompression (-d) en conservant le fichier original (-k) pour chaque nom de fichier qui lui a été passé, les uns après les autres.

Il est toutefois possible de lancer ces décompressions en parallèle (cf brew parallel) :

echo *.gz | parallel gzip -d -k

Ou encore :

parallel gzip -d -k ::: *.gz

Mais attention au goulot d'étranglement coté disque de toute façon, pas sur que le gain soit vraiment notable.

avatar Nicolas Furno | 

@ byte_order :

Oups, je me suis manifestement un petit peu trop avancé sur un terrain que je maîtrisais mal… je corrige, merci !

avatar bobdu87 | 

Pour le cas en question tout les fichiers sont sans doute encore en mémoire cache et même pas sur le disque/ssd à la fin de la décompression avec le terminal...

avatar byte_order | 

Vu leur taille, c'est très très probable en effet et à la limite le parallèlisme va plutôt avoir des effets négatif sur les cache miss entre la RAM et le CPU justement...

avatar marc_os | 

@bobdu87 :
Euh... Tu es sûr de ce que tu avances ?

avatar BeePotato | 

@ byte_order : « l'application gzip ensuite fait la même opération de décompression (-d) en conservant le fichier original (-k) pour chaque nom de fichier qui lui a été passé, les uns après les autres. »

Non. Ou plutôt : on n’en sait rien.
Le fait qu’on passe en un coup tous les noms de fichiers à une seule instance de gzip n’implique pas qu’il n’y a aucune parallélisation, gzip pouvant très bien avoir été écrit pour traiter plusieurs opérations en même temps sur plusieurs threads (j’ignore totalement si c’est le cas, n’ayant pas de temps à perdre à aller vérifier ça — je souligne juste que c’est tout à fait possible et qu’on ne peut arriver à aucune conclusion juste en lisant la ligne de commande).

avatar byte_order | 

@BeePotato

> Non. Ou plutôt : on n’en sait rien.

J'ai vérifié avant mon premier post, justement, pour etre sûr. Vous y trouverez, après le parsing des options, ceci :

while (optind < argc) {
treat_file(argv[optind++]);
}

Et la fonction treat_file() est purement séquentielle elle aussi.

> Le fait qu’on passe en un coup tous les noms de fichiers à une seule instance
> n’implique pas qu’il n’y a aucune parallélisation [...]
> on ne peut arriver à aucune conclusion juste en lisant la ligne de commande

Tout à fait, et je suis d'accord, on ne peut pas savoir à l'avance si le programme appelé va traiter séquentiellement ou pas les données distinctes qu'on lui passe en paramètre. Sur ce point vous avez raison de le souligner, ma réaction pouvant en effet laisser penser le contraire.

Il faut toutefois souligner aussi que l'immense partie des utilitaires en ligne de commande venues du monde Unix sont conçues selon le paradigme d'Unix, à savoir faire une seule chose mais le faire bien, et laisser au shell et autres outils de "workflow" les combiner pour faire des choses complexes et spécifiques. Le corollaire, c'est que dans l'immense majorité des cas les programmes en lignes de commande usuels d'Unix n'offrent donc pas de parallélisme intégré, laissant justement cela à des outils tel que "parallel", "make", etc.

avatar BeePotato | 

@ byte_order : « J'ai vérifié avant mon premier post, justement, pour etre sûr. Vous y trouverez, après le parsing des options, ceci : »

Ah, ok. J’aurais donc dû être plus précis dès la première ligne de mon commentaire.

Merci d’avoir vérifié. Par acquis de conscience, je suis du coup allé voir la version Darwin/FreeBSD de gzip, l’extrait donné ici venant de la version GNU. Le fonctionnement y est similaire, avec un traitement séquentiel des fichiers.

« Il faut toutefois souligner aussi que l'immense partie des utilitaires en ligne de commande venues du monde Unix sont conçues selon le paradigme d'Unix, à savoir faire une seule chose mais le faire bien, et laisser au shell et autres outils de "workflow" les combiner pour faire des choses complexes et spécifiques. Le corollaire, c'est que dans l'immense majorité des cas les programmes en lignes de commande usuels d'Unix n'offrent donc pas de parallélisme intégré, laissant justement cela à des outils tel que "parallel", "make", etc. »

Mouais. Je ne suis pas convaincu. Si on applique cette idée à la lettre, un tel outil ne devrait alors même pas accepter une liste de fichiers en argument, mais juste un seul nom de fichier.
Pour moi, à partir du moment où un logiciel s’engage à traiter des fichiers par lot (ce qu’il fait dès qu’il accepte en argument plus d’un nom de fichier à la fois), il peut bien en paralléliser le traitement, ça ne rompt pas son contrat avec le shell.

avatar Un Type Vrai | 

Si gzip n'acceptait qu'un seul argument a la fois, la parallelisation serait automatique et gérée par le kernel... Plutot plus efficace je pense.
D'ailleurs, il faudrait faire un benchmark avec d'un cote un gzip * et de l'autre 1000 gzip xx &...
Qui s'y colle ?

avatar BeePotato | 

@ Un Type Vrai : « Si gzip n'acceptait qu'un seul argument a la fois, la parallelisation serait automatique »

Non, elle ne serait pas automatique. Il faudrait qu’elle soit explicitement demandée par l’utilisateur (par exemple au moyen d’un « & », comme dans ton commentaire suivant).

« et gérée par le kernel... Plutot plus efficace je pense. »

Il n’y a pas de raison que ce soit plus efficace qu’une parallélisation faite en interne au moyen de threads.
Au contraire, il y aura forcément du temps perdu (même si minime par rapport au temps de traitement des fichiers), ne serait-ce que pour le lancement de chacun des gzip ainsi que pour la gestion de la boucle par le shell.

avatar caissonbulle | 

Bonjour, saurais-tu ajouter le code pour que la cible de la décompression soit le Bureau ?
Merci !... ;-)

avatar Nicolas R. | 

DINGUE ! Pour une nouvelle !

avatar Lapin85 | 

Oui et lui faut 15 secondes pour taper la ligne de commande ?

avatar bobdu87 | 

je suis désolé pour toi, tu as sans doute mis 1 minutes a écrire ce message avec ton index ;)

Puis bon c'est pas comme si la touche tabulation permettait bien souvent de raccourcir drastiquement le nombre de caractères à taper sans même parler des *.gz

avatar BeePotato | 

@ bobdu87 : « Puis bon c'est pas comme si la touche tabulation permettait bien souvent de raccourcir drastiquement le nombre de caractères à taper sans même parler des *.gz »

Il a tout de même raison sur un point : il était certes intéressant de comparer, comme c’est fait dans cette vidéo, la vitesse de traitement des deux outils, mais une autre comparaison, se focalisant sur l’intérêt pour l’utilisateur, est elle aussi pertinente. Et cette comparaison-là doit forcément inclure le temps d’accès à chaque outil (qui varie d’un utilisateur à l’autre, en fonction de sa maîtrise des divers outils).

avatar Un Type Vrai | 

Je fais un cd, un ls, un pwd, un git pull, un ... Bien plus rapidement sur un terminal.

Par contre je suis plus lent avec vi qu'avec nano ou ee...
La raison est simple, mon cerveau bloque toujours entre les deux modes de vi.
Et un type un peu plus doué que moi ira bien plus vite avec vi... (n'ayant pas besoin de constamment regarde en bas a couché pour savoir qui taper..)
Mais primo, un jour je m'y mettrai.

avatar BeePotato | 

@ Un Type Vrai : « Je fais un cd, un ls, un pwd, un git pull, un ... Bien plus rapidement sur un terminal. »

Comme je l’ai dit précédemment, ça dépend évidemment des utilisateurs… mais aussi des situations.
Que signifie « faire un cd (ou un ls) » sans plus de précision ? Rien, en fait. La vitesse relative de ces outils dépend de la situation dans laquelle on se trouve au moment de devoir les utiliser ainsi que de ce qu’on veut faire précisément.

On veut vérifier les infos de seulement quelques fichiers précis, sélectionnables facilement via une expression régulière sur leur nom ? Un ls sera bien plus rapide et efficace que le Finder.
Mais si on veut juste les infos de tous les fichiers du dossier courant, ça n’est pas plus rapide que le Finder (voire ça se retrouve plus lent si on veut alterner entre divers critères de tri), et le choix dépendra plutôt du logiciel dans lequel on se trouve à ce moment-là.
Et si on s’intéresse à des fichiers non sélectionnables par leur nom, mais plutôt par leur contenu ? Le Finder reprend l’avantage.

Quant au cd, pour des descentes et remontées dans une hiérarchie de dossiers, il fera à peu près jeu égal avec une fenêtre du Finder en présentation par colonnes — donc là encore, le choix se fera surtout en fonction de ce qu’on faisait avant et ce qu’on fera après cette navigation.
Mais il y a d’autres occasions de se déplacer dans les dossiers : par exemple, si on est en train de travailler sur un document quelconque et qu’on doit aller voir d’autres fichiers dans le même dossier que ce document, l’interface graphique permettra d’y aller beaucoup plus rapidement qu’un cd dans un terminal.
Même chose si on doit envoyer ce document vers une autre application (Mail, par exemple) — là, le passage par un terminal ne ferait que provoquer une perte de temps.

L’idéal est donc de bien maîtriser les deux environnements, connaître leurs points forts et points faibles, et savoir passer de l’un à l’autre quand il le faut.

avatar Ghaleon111 | 

3s si elle est déjà une grosse partie de la commande est en mémoire
En faite le terminal comme sur linux, c'est HYPER puissant et celui qui les maitrise va beaucoup plus vite pour tout que n'importe quel interface graphique

avatar heret | 

Ridicule, autant que ton orthographe et ta grammaire. Merci de ne pas nous demander de faire l'effort que tu ne veux pas faire.
Ici, dans un cas, il y a des décompressions en parallèle ce qui ne sert à rien puisqu'il y a le goulet d'étranglement du disque dur.
Et puis tout dépend de la façon dont ça a été programmé. Cette semaine, j'ai optimisé un batch en mode ligne de commande, donc sans interface graphique. Avant optimisation, ce batch traitait en plus de 10h un ensemble de fichiers. Après optimisation, ce même ensemble de fichier est traité en 45 secondes.

avatar Ghaleon111 | 

En faite tu fais le malin mais tu n'a même pas compris de quoi je parle MDR
De plus c'est LARGEMENT confirmer par tous les connaisseurs
Rien qu'avec la tabulation on gagne beaucoup de temps
Pour transférer sur une clé USB par exemple du temps que tu cherche les fichiers dans le finder, je suis déjà en train de les copier sur la clé USB et pour un tas d'action c'est pareil

avatar BeePotato | 

@ Ghaleon111 : « De plus c'est LARGEMENT confirmer par tous les connaisseurs »

Pas d’accord. Par exemple, je suis un connaisseur et je ne confirme pas ça du tout. :-)

« Pour transférer sur une clé USB par exemple du temps que tu cherche les fichiers dans le finder, je suis déjà en train de les copier sur la clé USB »

Ce n’est évidemment pas vrai dans tous les cas. Ça dépend d’où sont les fichiers à copier, mais aussi de leurs noms.
Par exemple, si les fichiers sont noyés au milieu d’un paquet d’autres et qu’il n’y a dans leurs noms aucun motif simple permettant de les sélectionner via une expression régulière, on ira probablement bien plus vite via le Finder.
Et si les fichiers sont des images, toutes nommées en IMG_kekchose et qu’on doit en copier juste quelques unes sur la base de leur contenu, l’aperçu de ce contenu que propose le Finder permettra d’aller beaucoup, beaucoup plus vite que via un terminal.

Bref, comme déjà dit, l’efficacité de l’une ou l’autre approche dépend (évidemment) de la situation à traiter (sans compter qu’il y a bien d’autres cas de manipulation de fichiers que la copie vers une clef USB).

avatar BeePotato | 

@ Ghaleon111 : « En faite le terminal comme sur linux »

Pourquoi « comme sur Linux » ? Ce n’est pas vraiment là que l’usage d’un terminal trouve son origine, hein.

« c'est HYPER puissant et celui qui les maitrise va beaucoup plus vite pour tout que n'importe quel interface graphique »

Non, pas pour tout (et c’est assez évident). Chaque outil a ses forces et ses faiblesses et sera plus ou moins adapté selon la situation. Idéalement, il faut maîtriser l’un comme l’autre et savoir choisir le bon au bon moment.

avatar Ghaleon111 | 

Je me fous de son origine, je parle de son efficacité et linux est l'os ou la ligne de commande permet de contrôler vraiment tout l'os et ces fonctions

L'interface graphique c'est très bien, pas de soucis mais depuis que je me suis intéressé aux lignes de commandes qui permettent aussi des choses que n'a pas accès l'interface graphique, je constate un gain de temps et manipulation pour un tas de choses

avatar BeePotato | 

@Ghaleon111 : « et linux est l'os ou la ligne de commande permet de contrôler vraiment tout l'os et ces fonctions »

Ce n’est pas le seul OS dans ce cas, c’est ce que je voulais faire remarquer.

« je constate un gain de temps et manipulation pour un tas de choses »

Pour un tas de choses, oui. Mais je signalais juste que l’affirmation comme quoi ça amenait un gain de temps pour tout est fausse.

avatar simnico971 | 

@Lapin85

Pas faux ?

avatar bobdu87 | 

Un autre militant du clavier à un doigt?

avatar macfredx | 

@Lapin85

Bien vu ?

avatar bobdu87 | 

Hum ça devient grave là, mais bon pas étonnant Apple vise maintenant une clientèle bien éloigné des pros...

avatar marc_os | 

@bobdu87 :
Qu'est-ce qui est grave ??
Tout est relatif. Si l'interface prend une seconde, c'est énorme comparé à qq. centièmes de seconde de décompression. Mais sitôt que tu décompresses un gros fichier, c'est rien.
Et le Terminal est là pour ceux qui sont à qq. secondes prêt !

avatar Mike Mac | 

A partir de ce constat, la rédaction va pouvoir nous proposer un autre excellent comparatif :

Raccourcis claviers VS Touchbar.

C'est le match attendu par beaucoup.

avatar cyrildruesne | 

À noter, Rob Griffiths était derrière le regretté et excellent osxhints.com.

avatar ovea | 

@cyrildruesne :
D'ailleurs comme le montre
l'article “Open a specific browser based on the URL”
ce dont a besoin pour faire des interactions avec une interface graphique, c'est des
handler comme ici handle_url …

Après il serait intéressant de rediriger la commande Shell gzip vers un handler avec une barre de progression à afficher (ce qui n'est pas garantie par l'interface … à moins d'une surprise)
Ensuite le système doit optimiser, grouper, mapper (cartographier) le choix d'exécution d'une option plus … rapide.

Et c'est ici, où la connectivité des commandes Shell UNIX et la programmation de l'interface graphique Apple différent.

Apple a sans doute oublié, comme toutes ces copines du pommier, la simplicité de l'outil d'enregistrement des handlers d'interface de commande … graphique !

La dissociation des processus d'affichage et de décompression en mémoire rend complexe les différents rapports de mise à jour réciproques par conséquent,
qu'est-ce qui pourrait encore une fois de plus simplifier ce rapport ?

avatar fredseg | 

Il me semble avoir lu que certains programmes ralentissent l'exécution car sinon l'utilisateur a l'impression qu'il ne s'est rien passé. Je ne sais pas si c'est le cas ici mais d'après ce que j'ai retenu ce serait assez répandu dans le domaine des interfaces web.

avatar byte_order | 

Oui, c'est souvent le cas dans les frontends de services Web.

On simule un début de tâche, tâche en cours, et fin de tâche côté frontend alors qu'en pratique côté backend on a déjà le résultat. C'est une question de feedback pour l'utilisateur (il risquereait de ne pas percevoir que le résultat est déjà là et penserait à une erreur et recliquerait - c'est très fréquent cette situation).

Mais c'est aussi (surtout ?) une question de valeur ajoutée perçue vs réelle. Une tâche rapide peut l'être pour des tas de raisons, mais à l'instar du temps de travail vs productivité réelle, une tâche longue est perçue comme une tâche complexe et donc à forte valeur ajoutée, tandis que la rapidité est perçue comme à faible valeur, bâclée.

C'est idiot, un comble, mais c'est comme ça.

avatar Boumy | 

Merci, j'allais l'écrire. Grâce à toi, ça me prendra moins de temps (sais pas ce que j'ai, mais j'ai une de ces flemmes, pour le moment…). J'avais lu aussi qu'il fallait donner l'impression à l'utilisateur que son appareil produisait un effort pour traiter les demandes.

avatar Wolf | 

Sauf que moi il vas me falloir 30 minutes pour taper la ligne de commande que je dois aller chercher sur internet au préalable ;)

avatar macfredx | 

@Wolf

30 minutes minimum... ??

Pages

CONNEXION UTILISATEUR