Posté par Marotte ⛧ .
En réponse au journal Args parser pour shell.
Évalué à 5.
Dernière modification le 25 février 2024 à 00:52.
C’est plus le fork lié au pipe lié à l’utilisation de cat dans ce cas.
une très précieuse milliseconde à se lancer
« Se lancer » regroupe plusieurs étapes mais je ne vais pas détaillr. Un fork est un fork et c’est ça qu’il est important de limiter, car il a un coût, c’est peut-être même inférieur à la milliseconde mais ça ne change strictement rien à ce que je dis : 500μs * 10000000 = 50s
tu peux passer -l comme argument à grep pour éviter de lire tout le fichier s’il trouve ta correspondance à la deuxième ligne.
C’est une très bonne remarque, mais d’une : le « plus d’économie » il dépend de la taille du fichier, vu qu’on ne l’affiche pas, s’il fait 4k et qu’il est en RAM la différence avec le fork nécessaire est pas si évidente que ça. Par ailleurs comme très justement signalé plus bas, le fait d’utiliser -q (sans le -c) fait que le fichier ne sera lu que jusqu’à la première occurrence, le -l est superflu. Utiliser le -q sans le -c n’est donc pas seulement avantageux en terme de lisibilité du code comme je l’affirmait à tort.
en conditions réelles.
Une fois de plus, si les conditions réelles sont de traiter 10 fichiers de 1M lignes et de faire ça 48 fois par jour, ça fait une différence significative.
Je finis sur deux points car je sais qu’on peut/va me les opposer :
1) Si le traitement doit être lancé aussi souvent sur de tels volumes alors on gagnera davantage à écrire le traitement dans un langage compilé. Sur cette remarque qui paraît à beaucoup relever du bon sens même, j’ai deux choses à faire remarquer :
Le développement, le déploiement et la maintenance d’un langage compilé a une complexité supérieure dans bien des cas et demande une charge de travail plus importante et des compétences différentes, compétences qui sont à ma connaissance plus rares en terme de ressource humaine, plus coûteuses, et potentiellement utilisables (et utilisées) sur des travaux qui ont souvent une plus forte valeur ajoutée pour l’entreprise.
Si c’est pour pondre un code C aussi mal optimisé que le script Bash qu’il remplace, le gain peut même être inférieur à celui qu’une bonne optimisation du Bash existant (si c’est par exemple l’algorithme qu’on aurait pu optimiser, où l’ajout d’un cache, etc...)
Tout ça pour dire que passer d’un langage de script très connu à un langage compilé pour uniquement résoudre un problème de performance qu’on peut résoudre simplement en corrigeant l’écriture imparfaite d’une script shell existant (ie: en l’optimisant) je doute que ce soit pertinent très souvent, et clairement pas une évidence.
2) Tout ce que je dis sur les UUOC et autres constructions non optimales dans un script Bash c’est évidemment préférable de les éviter dès le départ. Mais, premièrement on ne les évitera pas toute, donc une phase d’optimisation final une fois l’aspect fonctionnel du script terminé est toujours la bienvenue. De ce fait, une trop grande attention portée à l’optimisation et temps passé sur le sujet dans les phases initiales du développement est contre-productive. Et ça ça ne concerne pas que les langages interprétés.
Tout en évitant de partir sur une architecture logiciel qui arrivera immanquablement à un programme trop lent car inadaptée. Il faut mieux un programme qui répond au cahier des charges sur les fonctionnalités malgré qu’il soit trop lent, et ainsi pouvoir se concentrer sur son optimisation en ayant une vue d’ensemble. Que d’étudier dans le détail la meilleure manière d’écrire telle fonction bas-niveau alors qu’on a fait genre à peine 20% des fonctions de plus haut niveau... C’est un travers assez courant chez tout développeur (sauf ce pour qui l’optimisation n’est même pas une pré-occupation à un seul instant, évidemment ^^), moi le premier, mais dont il s’agit de chercher à réduire l’importance.
[^] # Re: getopt(1)
Posté par Marotte ⛧ . En réponse au journal Args parser pour shell. Évalué à 5. Dernière modification le 25 février 2024 à 00:52.
C’est plus le fork lié au pipe lié à l’utilisation de cat dans ce cas.
« Se lancer » regroupe plusieurs étapes mais je ne vais pas détaillr. Un fork est un fork et c’est ça qu’il est important de limiter, car il a un coût, c’est peut-être même inférieur à la milliseconde mais ça ne change strictement rien à ce que je dis : 500μs * 10000000 = 50s
C’est une très bonne remarque, mais d’une : le « plus d’économie » il dépend de la taille du fichier, vu qu’on ne l’affiche pas, s’il fait 4k et qu’il est en RAM la différence avec le fork nécessaire est pas si évidente que ça. Par ailleurs comme très justement signalé plus bas, le fait d’utiliser -q (sans le -c) fait que le fichier ne sera lu que jusqu’à la première occurrence, le -l est superflu. Utiliser le -q sans le -c n’est donc pas seulement avantageux en terme de lisibilité du code comme je l’affirmait à tort.
Une fois de plus, si les conditions réelles sont de traiter 10 fichiers de 1M lignes et de faire ça 48 fois par jour, ça fait une différence significative.
Je finis sur deux points car je sais qu’on peut/va me les opposer :
1) Si le traitement doit être lancé aussi souvent sur de tels volumes alors on gagnera davantage à écrire le traitement dans un langage compilé. Sur cette remarque qui paraît à beaucoup relever du bon sens même, j’ai deux choses à faire remarquer :
Tout ça pour dire que passer d’un langage de script très connu à un langage compilé pour uniquement résoudre un problème de performance qu’on peut résoudre simplement en corrigeant l’écriture imparfaite d’une script shell existant (ie: en l’optimisant) je doute que ce soit pertinent très souvent, et clairement pas une évidence.
2) Tout ce que je dis sur les UUOC et autres constructions non optimales dans un script Bash c’est évidemment préférable de les éviter dès le départ. Mais, premièrement on ne les évitera pas toute, donc une phase d’optimisation final une fois l’aspect fonctionnel du script terminé est toujours la bienvenue. De ce fait, une trop grande attention portée à l’optimisation et temps passé sur le sujet dans les phases initiales du développement est contre-productive. Et ça ça ne concerne pas que les langages interprétés.
Tout en évitant de partir sur une architecture logiciel qui arrivera immanquablement à un programme trop lent car inadaptée. Il faut mieux un programme qui répond au cahier des charges sur les fonctionnalités malgré qu’il soit trop lent, et ainsi pouvoir se concentrer sur son optimisation en ayant une vue d’ensemble. Que d’étudier dans le détail la meilleure manière d’écrire telle fonction bas-niveau alors qu’on a fait genre à peine 20% des fonctions de plus haut niveau... C’est un travers assez courant chez tout développeur (sauf ce pour qui l’optimisation n’est même pas une pré-occupation à un seul instant, évidemment ^^), moi le premier, mais dont il s’agit de chercher à réduire l’importance.