Si ce n'est que je lance un process Perl pour chaque traitement.
Alors pourquoi pas plutôt faire un script unique, plus conséquent, qui fasse tous les traitements ?
Je connais très bien Perl, mais je me force justement à éviter de l'utiliser quand il existe d'autres solutions beaucoup plus légère, éviter d'utiliser un bulldozer pour écraser une mouche.
Pour ma part, à l'inverse, c'est mon temps que j'essaie d'économiser plus que celui de la machine.
Aussi, je pars directement sur Perl. Comme ça, quand je m'aperçois qu'il est souhaitable de faire un traitement plus compliqué que prévu et que l'outil qui m'aurait semblé suffisant au départ ne l'est plus, eh bien je ne perds pas de temps à convertir ce que j'avais déjà fait en Perl, parce que ça y est depuis le départ.
C'est un bon réflexe je pense.
Je ne suis pas convaincu que ce choix ait dans l'informatique actuelle autant de portée qu'il en aurait eu auparavant.
Pour égaler avec Perl la charge infligée sur un poste de travail par un navigateur web soit-disant léger comme Firefox ou par OpenOffice, ou sur un serveur par un truc "hyper-efficace" comme OpenLDAP, il faut vraiment que le traitement soit très lourd, ou alors qu'on l'ait programmé comme un pied. La lourdeur due au temps de lancement ou à l'encombrement mémoire de Perl par rapport à bash, sed ou awk est alors négligeable...
Je dis ça par expérience personnelle.
Sur le PIII 450 (avec 512 Mo quand même) que j'ai encore comme poste de travail pour quelques semaines, les trucs les plus lourds que j'utilise sont Firefox, xpdf et OpenOffice; la machine serait encore assez puissante pour tout le reste. Je n'ouvre généralement pas documents Word que je reçois en attachement de mail : la plupart du temps, l'intérêt du contenu ne vaut pas le temps que met OpenOffice à se lancer.
J'utilise OpenLDAP sur un serveur et je faisais sur l'annuaire un traitement nécessitant un nombre conséquent de requêtes assez lourdes. J'en ai eu marre que ça me charge le serveur pendant plusieurs minutes. Maintenant, je charge directement tout l'annuaire avec un dump au niveau du backend (donc en court-circuitant OpenLDAP) et je fais tous les traitements en interne de mon script Perl. C'est carrément plus rapide. Et encore j'ai utilisé par facilité les structures fournies d'origine par Perl (tableau associatif notamment), plutôt que des structures plus optimales dans ce cas (par exemple un arbre pour stocker l'annuaire). Sans importance : mes traitements sont encore nettement moins longs que le chargement de l'annuaire, pourtant pas plus long qu'une seule grosse requête sur OpenLDAP.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # To Perl or not to Perl
Posté par Arthur Accroc . En réponse au message Motif multi-lignes avec 'sed'. Évalué à 2.
Alors pourquoi pas plutôt faire un script unique, plus conséquent, qui fasse tous les traitements ?
Pour ma part, à l'inverse, c'est mon temps que j'essaie d'économiser plus que celui de la machine.
Aussi, je pars directement sur Perl. Comme ça, quand je m'aperçois qu'il est souhaitable de faire un traitement plus compliqué que prévu et que l'outil qui m'aurait semblé suffisant au départ ne l'est plus, eh bien je ne perds pas de temps à convertir ce que j'avais déjà fait en Perl, parce que ça y est depuis le départ.
Je ne suis pas convaincu que ce choix ait dans l'informatique actuelle autant de portée qu'il en aurait eu auparavant.
Pour égaler avec Perl la charge infligée sur un poste de travail par un navigateur web soit-disant léger comme Firefox ou par OpenOffice, ou sur un serveur par un truc "hyper-efficace" comme OpenLDAP, il faut vraiment que le traitement soit très lourd, ou alors qu'on l'ait programmé comme un pied. La lourdeur due au temps de lancement ou à l'encombrement mémoire de Perl par rapport à bash, sed ou awk est alors négligeable...
Je dis ça par expérience personnelle.
Sur le PIII 450 (avec 512 Mo quand même) que j'ai encore comme poste de travail pour quelques semaines, les trucs les plus lourds que j'utilise sont Firefox, xpdf et OpenOffice; la machine serait encore assez puissante pour tout le reste. Je n'ouvre généralement pas documents Word que je reçois en attachement de mail : la plupart du temps, l'intérêt du contenu ne vaut pas le temps que met OpenOffice à se lancer.
J'utilise OpenLDAP sur un serveur et je faisais sur l'annuaire un traitement nécessitant un nombre conséquent de requêtes assez lourdes. J'en ai eu marre que ça me charge le serveur pendant plusieurs minutes. Maintenant, je charge directement tout l'annuaire avec un dump au niveau du backend (donc en court-circuitant OpenLDAP) et je fais tous les traitements en interne de mon script Perl. C'est carrément plus rapide. Et encore j'ai utilisé par facilité les structures fournies d'origine par Perl (tableau associatif notamment), plutôt que des structures plus optimales dans ce cas (par exemple un arbre pour stocker l'annuaire). Sans importance : mes traitements sont encore nettement moins longs que le chargement de l'annuaire, pourtant pas plus long qu'une seule grosse requête sur OpenLDAP.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone