HTML::Template -- une tortue ?

À (at) Fri, 01 Jul 2005 00:41:47 +0200,
"Jul" <julien@mesnews> écrivait (wrote):

Dans le développement d'un site internet, j'expérimente les modules
HTML::Template et HTML::Template::Expr et j'ai un énorme problème de lenteur
(une requete débouche sur un affichage après 2 secondes en moyenne).
[...]

Une telle lenteur est-elle normale ?

Ça dépend de nombreux facteurs : ce que vous faites dans votre code, la
machine sur laquelle ça tourne, si c'est en mod_perl ou en CGI classique, la
qualité de la connexion, etc.

D'autre part, j'ai essayé d'installer un module IPC::Shared, mais là, je n'y
comprends plus rien et je crains que ce module ne soit une interface à un
programe, ce qui expliquerait l'impossibilité de l'installer convenablement
(ou au moins que le 'make test' ne renvoit que des erreurs ^^)

Je ne connais pas ce module (il n'existe pas sur CPAN...). Vu son nom, on se
doute de ce qu'il peut faire.

Savez-vous faire marcher (tutoriel en ligne bienvenu) IPC::Shared avec
HTML::Template sur un hébergeur distant ? (où il faut donc tout installer
dans le répertoire personnel)

Mais pourquoi croyez-vous en avoir besoin ?

Ou autremement, connaissez vous un moteur de templates plus rapide que
HTML::Template et qui inclue également les fonctionnalités de
HTML::Template::Expr (qui en tant que développeur me sont fondamentales... )

La FAQ de HTML::Template est pourtant claire :

9- Question : Comme puis-je exécuter un programme à l'intérieur de mon
modèle ?

Réponse courte : vous ne pouvez pas. Réponse longue : vous ne devez pas
puisque que cela viole le concept fondamental de HTML::Template - que le
design et le code doivent être séparés.

Si vous croyez tout de même avoir absolument besoin de HTML::Template::Expr,
c'est que vous n'avez pas compris la philosophie de HTML::Template (et de
nombreux autres modules de gestion de templates qui prône la même chose).

Au passage, c'est peut-être l'utilisation de HTML::Template::Expr qui ralentit
votre script...

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Le 01 juil. 2005, Jul a écrit dans fr.comp.lang.perl :

Dans le développement d'un site internet, j'expérimente les modules
HTML::Template et HTML::Template::Expr et j'ai un énorme problème de
lenteur (une requete débouche sur un affichage après 2 secondes en
moyenne).

J'utilise beaucoup HTML::Template (tout seul) sur mon ordi perso (donc pas
en prod), et je n'ai jamais eu de tels ralentissements (cpu : P3 866).
J'aime d'ailleur bien ce module pour sa rapidité ! (alors que je n'utilise
même pas mod_perl).

AMHA, HTML::Template::Expr est surrement en cause. N'est-il donc
vraiment pas possible de séparer la partie programmation de la partie
présentation ?

J'appelle environ 3 modèles par requête

Ca fait beaucoup.

par le module HTML::Template::Expr pour lequel j'ai défini une unique
fonction globale &env qui me permet de récupérer les valeurs du HASH
%ENV, rien de plus.

Pourquoi ne pas utiliser une "boucle" dans le template au lieu d'une telle
fonction ?

Exemple (pas testé) :
Dans le CGI :
my @tmp_array ;
foreach (keys %ENV) {
push(@tmp_array, { NOM => $_ , VAL => $ENV{$_} }) ;
} ;
$template->param(ENV => @tmp_array) ;

Dans le template :
<table><TMPL_LOOP NAME=ENV>
<tr><td><TMPL_VAR NOM></td>
<td><TMPL_VAR VAL></td>
</tr>
</TMPL_LOOP></table>

Ou autremement, connaissez vous un moteur de templates plus rapide que
HTML::Template et qui inclue également les fonctionnalités de
HTML::Template::Expr (qui en tant que développeur me sont
fondamentales... )

L'auteur d'HTML::Template::Expr parle de HTML::Mason.

Paul Gaborit vient de nous annoncer :

"Jul" <julien@mesnews> écrivait (wrote):

Dans le développement d'un site internet, j'expérimente les modules
HTML::Template et HTML::Template::Expr et j'ai un énorme problème de lenteur
(une requete débouche sur un affichage après 2 secondes en moyenne). [...]
Une telle lenteur est-elle normale ?

Ça dépend de nombreux facteurs : ce que vous faites dans votre code, la
machine sur laquelle ça tourne, si c'est en mod_perl ou en CGI classique, la
qualité de la connexion, etc.

Je ne connais pas la machine physique malheureusement. Uniquement l'OS,
la version de PERL, le script tourne en CGI sur un serveur mutualisé
d'OVH (ne sachant pas s'il est possible d'utiliser mod_perl).
La connection n'est pas un soucis. Les pages statiques sont très
rapides. Peut-être, il est vrai, devrais-je aussi m'assurer de la
qualité des échanges SQL pour la rapidité d'execution

D'autre part, j'ai essayé d'installer un module IPC::Shared, mais là, je n'y
comprends plus rien et je crains que ce module ne soit une interface à un
programe, ce qui expliquerait l'impossibilité de l'installer convenablement
(ou au moins que le 'make test' ne renvoit que des erreurs ^^)

Je ne connais pas ce module (il n'existe pas sur CPAN...). Vu son nom, on se
doute de ce qu'il peut faire.

Savez-vous faire marcher (tutoriel en ligne bienvenu) IPC::Shared avec
HTML::Template sur un hébergeur distant ? (où il faut donc tout installer
dans le répertoire personnel)

Mais pourquoi croyez-vous en avoir besoin ?

Désolé d'avoir écorché le nom. Il s'agit de IPC::SharedCache.
J'en aurai besoin dans la mesure où la phase de compilation n'est plus
nécessaire dans HTML::Template, une fois le premier modèle compilé et
mise en cache, ce qui, d'après l'auteur accélère le fonctionnement de
HTML::Template.

Ou autremement, connaissez vous un moteur de templates plus rapide que
HTML::Template et qui inclue également les fonctionnalités de
HTML::Template::Expr (qui en tant que développeur me sont fondamentales... )

La FAQ de HTML::Template est pourtant claire :

9- Question : Comme puis-je exécuter un programme à l'intérieur de mon
modèle ?

Réponse courte : vous ne pouvez pas. Réponse longue : vous ne devez pas
puisque que cela viole le concept fondamental de HTML::Template - que le
design et le code doivent être séparés.

Si vous croyez tout de même avoir absolument besoin de HTML::Template::Expr,
c'est que vous n'avez pas compris la philosophie de HTML::Template (et de
nombreux autres modules de gestion de templates qui prône la même chose).

L'objectif d'utilisation est de faciliter l'injection de modèles dans
un modèle parent.
Comme je le disait, j'utilise pour le moment environ 3 modèles
encastrables dans un modèle de base, avec en plus d'autres modèles fils
dans le futur.
Cependant, par l'utilisation de HTML::Template (sans module
d'extension), celà n'est possible que par l'utilisation de 'tmpl_if' et
'tmpl_else', accompagnés de multiples 'tmpl_include'. Et dès lors, il
n'est pas possible d'inclure des modèles de manière dynamique car il
est nécessaire de connaître le nom de fichier (sans possibilité
d'utiliser de variable) du modèle inclu au moment de la conception
modèle parent.
Ce problème me pose donc une contraite majeure : je dois utiliser
plusieurs appels à HTML::Template pour chaque sous-modèle et les
injecter ensuite dans le modèle parent qui requière un nouvel appel à
HTML::Template. Idéalement, je considère pouvoir générer tout le
document de sortie par le moyen d'un seul et unique moteur de template,
qui serait capable d'injecter des sous-modèles en run-time. A ce moment
là, je ne serai plus contraint par l'utilisation de fonctions, car je
dois l'avouer, celles-ci ne me servent qu'à pouvoir simuler des
variables globales :

La fonction &env dont je parlais récupère les valeurs du tableau %ENV
et je l'ai déclarée globalement au chargement du module
HTML::Template::Expr pour ne pas avoir à la redéclarer à chaque nouveau
traitement de modèle.
Les autres fonctions que je prévoyais avaient la même utilité.

La deuxième raison de l'utilisation du module HTML::Tempalte::Expr est
de pouvoir bénéficier d'un batterie de test indispensable et plus
étendue que celle fournie par 'tmpl_if', ce qui simplifie visuellement
le développement des modèles : j'économise considérablement son
utilisation et celà clarifie le document.

Au passage, c'est peut-être l'utilisation de HTML::Template::Expr qui
ralentit votre script...

Oui, celà y contribue et c'est pour celà aussi que je proposais une
réorientation vers un module plus adapté, car comme vous pouvez le
voir, ce module m'est présentement indispensable avec HTML::Tempalte.
Je comptais donc sur vos expériences dans l'utilisation des modèles
pour y voir un peu plus clair.
A terme, je pense recourir au développement d'un module, ou la
recherche d'une méthode de transmission de l'information adaptée au
dynamisme désiré.


Merci pour votre réponse.


Julien

--
Jul... réapparru comme par enchantement

Le 01 juil. 2005, Jul a écrit dans fr.comp.lang.perl :

L'objectif d'utilisation est de faciliter l'injection de modèles dans
un modèle parent.
Comme je le disait, j'utilise pour le moment environ 3 modèles
encastrables dans un modèle de base, avec en plus d'autres modèles
fils dans le futur.
Cependant, par l'utilisation de HTML::Template (sans module
d'extension), celà n'est possible que par l'utilisation de 'tmpl_if'
et 'tmpl_else', accompagnés de multiples 'tmpl_include'. Et dès lors,
il n'est pas possible d'inclure des modèles de manière dynamique car
il est nécessaire de connaître le nom de fichier (sans possibilité
d'utiliser de variable) du modèle inclu au moment de la conception
modèle parent.

Pour les mêmes raisons que celles évoquées par Paul G. l'utilisation de
tmpl_if et tmpl_include est "limite". Il est toujours préférable de gérer
ce genre de chose en amont, dans le CGI. Là il est possible d'ouvrir tous
les modèles que l'on souhaite, définis par des variables etc...
Dans le genre :
my $mod_base = HTML::Template->new(filename => "base.html") ;
$mod_base->param(%vals_base) ;
my $mod_included = HTML::Template->new(filename => find_inc(%vals_base));
$mod_included->param(%vals_inc) ;
print $mod_base->output() ;
print $mod_included->output() ;

A noter qu'on peut même essayer des trucs comme :
my $mod_included = HTML::Template->new(filename => find_inc(%vals_base));
$mod_included->param(%vals_inc) ;
$vals_base{INSIDE} = $mod_included->output() ;
my $mod_base = HTML::Template->new(filename => "base.html") ;
$mod_base->param(%vals_base) ;
print $mod_base->output() ;

A ce moment là, je ne serai plus contraint par l'utilisation de
fonctions, car je dois l'avouer, celles-ci ne me servent qu'à pouvoir
simuler des variables globales :

Je ne comprend pas le raisonnement qui vous a poussé à utiliser des
fonctions pour représenter des variables (cf mon précédent post).

La deuxième raison de l'utilisation du module HTML::Tempalte::Expr est
de pouvoir bénéficier d'un batterie de test indispensable et plus
étendue que celle fournie par 'tmpl_if', ce qui simplifie visuellement
le développement des modèles : j'économise considérablement son
utilisation et celà clarifie le document.

La même structure de document doit être possible en n'utilisant que
tmpl_if. Il suffit de faire les test dans le CGI et de stocker leur
résultat dans un paramètre (ou pas).

Au passage, c'est peut-être l'utilisation de HTML::Template::Expr qui
ralentit votre script...

Oui, celà y contribue et c'est pour celà aussi que je proposais une
réorientation vers un module plus adapté, car comme vous pouvez le
voir, ce module m'est présentement indispensable avec HTML::Template.

Non, je ne crois pas.

Bonjour,

Jogo a formulé ce vendredi :

Pour les mêmes raisons que celles évoquées par Paul G. l'utilisation de
tmpl_if et tmpl_include est "limite". Il est toujours préférable de gérer
ce genre de chose en amont, dans le CGI. Là il est possible d'ouvrir tous
les modèles que l'on souhaite, définis par des variables etc...
Dans le genre :
my $mod_base = HTML::Template->new(filename => "base.html") ;
$mod_base->param(%vals_base) ;
my $mod_included = HTML::Template->new(filename => find_inc(%vals_base));
$mod_included->param(%vals_inc) ;
print $mod_base->output() ;
print $mod_included->output() ;

A noter qu'on peut même essayer des trucs comme :
my $mod_included = HTML::Template->new(filename => find_inc(%vals_base));
$mod_included->param(%vals_inc) ;
$vals_base{INSIDE} = $mod_included->output() ;
my $mod_base = HTML::Template->new(filename => "base.html") ;
$mod_base->param(%vals_base) ;
print $mod_base->output() ;

Cette deuxième solution est celle que j'ai adoptée justement.
L'utilisation de la fonction a été choisie pour ne pas redéclarer
plusieurs fois les mêmes variables dans chaque objet template créé.
Autrement, il est vrai que la solution que vous proposiez dans votre
précédent post serait la plus efficace. Et l'est peut-être même dans
cette situation si, comme avec TMPL::Template::Expr, je peux déclarer
les variables de manière globale pour le Namespace HTML::Template (qui
seraient donc héritées dans toutes les classes référencées et
accessibles depuis les modèles), mais je ne sais comment faire n'ayant
trouvé aucune référence dans la doc.

A ce moment là, je ne serai plus contraint par l'utilisation de
fonctions, car je dois l'avouer, celles-ci ne me servent qu'à pouvoir
simuler des variables globales :

Je ne comprend pas le raisonnement qui vous a poussé à utiliser des
fonctions pour représenter des variables (cf mon précédent post).

Dans un premier temps, pour l'accès large permis à cette fonction par
HTML::Template::Expr. Toutes les fonctions précédemment déclarées au
chargement du module peuvent être accessibles depuis toute référence
créée en OO.

La deuxième raison de l'utilisation du module HTML::Tempalte::Expr est
de pouvoir bénéficier d'un batterie de test indispensable et plus
étendue que celle fournie par 'tmpl_if', ce qui simplifie visuellement
le développement des modèles : j'économise considérablement son
utilisation et celà clarifie le document.

La même structure de document doit être possible en n'utilisant que
tmpl_if. Il suffit de faire les test dans le CGI et de stocker leur
résultat dans un paramètre (ou pas).

Pas exactement ou alors celà surcharge un peu la programmation.
Principalement, ces tests avancés dont j'ai besoin concerne des
boucles et des conditions concernant (au moins) deux variables
transmises. Etant donné que c'est pour formatter l'affichage (syntaxe
du language humain par exemple), il est plus aisé de pouvoir pratiquer
deux ou trois tests dans deux ou trois intérations de 'tmpl_if' que
d'utiliser jusqu'à 6 itérations de 'tmpl_if'.
C'est sûr, l'utilisation de 'tmpl_if' uniquement est faisable, mais
laborieuse.

Au passage, c'est peut-être l'utilisation de HTML::Template::Expr qui
ralentit votre script...

Oui, celà y contribue et c'est pour celà aussi que je proposais une
réorientation vers un module plus adapté, car comme vous pouvez le
voir, ce module m'est présentement indispensable avec HTML::Template.

Non, je ne crois pas.

C'est à voir, mais je suis tombé sur cette extension justement parce
que je recherchais ce type de comportement.
Comme vous le proposiez précédemment, je vais évaluer HTML::Mason, en
espérant que cette fois ci, par contre, je ne me retrouverai pas face à
une bête difficile à dompter et un module trop démesuré pour
l'utilisation que j'en aurai.


Merci


Julien

--
Jul... réapparru comme par enchantement

À (at) Fri, 01 Jul 2005 12:33:13 +0200,
"Jul" <julien@mesnews> écrivait (wrote):
[...]

La connection n'est pas un soucis. Les pages statiques sont très
rapides. Peut-être, il est vrai, devrais-je aussi m'assurer de la qualité des
échanges SQL pour la rapidité d'execution

Puisque vous utilisez un SGBD et puisque c'est du CGI classique (on sait quand
on fait du mod_perl), l'établissement d'une connexion entre le script CGI et
le SGBD a lieu à chaque requête. Cela peut-être très long (cas de Oracle par
exemple), très court (cas de MySQL) ou entre les deux (cas de
PostgreSQL). Mais dans tous les cas, ce temps n'est pas négligeable...

Désolé d'avoir écorché le nom. Il s'agit de IPC::SharedCache.
J'en aurai besoin dans la mesure où la phase de compilation n'est plus
nécessaire dans HTML::Template, une fois le premier modèle compilé et mise en
cache, ce qui, d'après l'auteur accélère le fonctionnement de HTML::Template.

En fait, cela permet de stocker le résultat de la compilation d'un template
dans un segment de mémoire partagée que les différentes instances de votre
script iront consulter ensuite. Mais je ne suis pas sûr que l'utilisation d'un
segment de mémoire partagée soit possible sur un serveur mutualisé... À voir.

De plus IPC::SharedCache fait en fait appel à IPC::ShareLite qui nécessite
l'accès à un compilateur C pour s'installer. Avez-vous accès à cela sur votre
serveur ? À moins que IPC::ShareLite soit déjà installé...

On peut aussi faire de "l'IPC du pauvre" en utilisant le module Storable pour
stocker l'état d'une structure dans un fichier. J'utilise souvent cette
méthode avec bonheur.

L'objectif d'utilisation est de faciliter l'injection de modèles dans un
modèle parent.

Comme le dit un autre contributeur, cela me semble faisable sans pour autant
utiliser HTML::Template::Expr.

Sinon, il existe un autre outil de template : Template-Toolkit. Il est
beaucoup plus général que HTML::Template et n'est sûrement pas plus simple à
installer/utiliser. Nous l'utilisons ici car il est performant, généraliste et
customisable grâce aux plugins (pour le meilleur comme pour le pire).

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Paul Gaborit a exposé le 01/07/2005 :

À (at) Fri, 01 Jul 2005 12:33:13 +0200,
"Jul" <julien@mesnews> écrivait (wrote):
[...]

La connection n'est pas un soucis. Les pages statiques sont très
rapides. Peut-être, il est vrai, devrais-je aussi m'assurer de la qualité
des échanges SQL pour la rapidité d'execution

Puisque vous utilisez un SGBD et puisque c'est du CGI classique (on sait
quand on fait du mod_perl), l'établissement d'une connexion entre le script
CGI et le SGBD a lieu à chaque requête. Cela peut-être très long (cas de
Oracle par exemple), très court (cas de MySQL) ou entre les deux (cas de
PostgreSQL). Mais dans tous les cas, ce temps n'est pas négligeable...

Il s'agit de MySQL, en effet. Ce que je crains à ce sujet, c'est que le
serveur soit situé sur une autre machine du réseau local, ce qui
impliquerait déjà une légère augmentation du temps de réponse.

Désolé d'avoir écorché le nom. Il s'agit de IPC::SharedCache.
J'en aurai besoin dans la mesure où la phase de compilation n'est plus
nécessaire dans HTML::Template, une fois le premier modèle compilé et mise
en cache, ce qui, d'après l'auteur accélère le fonctionnement de
HTML::Template.

En fait, cela permet de stocker le résultat de la compilation d'un template
dans un segment de mémoire partagée que les différentes instances de votre
script iront consulter ensuite. Mais je ne suis pas sûr que l'utilisation
d'un segment de mémoire partagée soit possible sur un serveur mutualisé... À
voir.

J'ai pensé à ce type de problème en effet, étant donné que j'ai essayé
d'installer IPC::ShareLite avec. J'imaginais aussi le recours à un
autre programme encore, mais n'ai pas vérifié la doc de IPC::ShareLite.

De plus IPC::SharedCache fait en fait appel à IPC::ShareLite qui nécessite
l'accès à un compilateur C pour s'installer. Avez-vous accès à cela sur votre
serveur ? À moins que IPC::ShareLite soit déjà installé...

On peut aussi faire de "l'IPC du pauvre" en utilisant le module Storable pour
stocker l'état d'une structure dans un fichier. J'utilise souvent cette
méthode avec bonheur.

C'est justement ce que je cherchais. Créer un dossier de cache pour
accueillir les compilations de modèles. Et n'arrivant pas à
différencier chaque type de cache manipulé par HTML::Template, j'ai cru
que IPC::SharedCache gérait aussi le cache sous forme de fichiers, soit
qu'il était nécessaire pour tout type d'utilisation du cache... Une
chose que je dois approfondir donc.

L'objectif d'utilisation est de faciliter l'injection de modèles dans un
modèle parent.

Comme le dit un autre contributeur, cela me semble faisable sans pour autant
utiliser HTML::Template::Expr.

Sinon, il existe un autre outil de template : Template-Toolkit. Il est
beaucoup plus général que HTML::Template et n'est sûrement pas plus simple à
installer/utiliser. Nous l'utilisons ici car il est performant, généraliste
et customisable grâce aux plugins (pour le meilleur comme pour le pire).

J'ai aperçu celà par une recherche google je vais me pencher dessus.


Merci,

Julien

--
Jul... réapparru comme par enchantement

À (at) Fri, 01 Jul 2005 15:19:04 +0200,
"Jul" <julien@mesnews> écrivait (wrote):

Il s'agit de MySQL, en effet. Ce que je crains à ce sujet, c'est que le
serveur soit situé sur une autre machine du réseau local, ce qui impliquerait
déjà une légère augmentation du temps de réponse.

Sur un réseau local rapide (ce qui est certainement le cas actuellement), vous
ne verrez quasiment pas de différence entre une instance locale et une
instance distante... sauf bien sûr si le réseau est saturé.

On peut aussi faire de "l'IPC du pauvre" en utilisant le module Storable
pour stocker l'état d'une structure dans un fichier. J'utilise souvent
cette méthode avec bonheur.

C'est justement ce que je cherchais. Créer un dossier de cache pour
accueillir les compilations de modèles. Et n'arrivant pas à différencier
chaque type de cache manipulé par HTML::Template, j'ai cru que
IPC::SharedCache gérait aussi le cache sous forme de fichiers, soit qu'il
était nécessaire pour tout type d'utilisation du cache... Une chose que je
dois approfondir donc.

L'utilisation de 'Storable' est très simple. Pour stocker l'objet $obj :

store $obj, $filename; # (*)

Pour recréer cet objet :

$obj = retrieve $filename;

La seule limitiation c'est d'éventuelles références à du code dans
l'objet. Mais je ne pense pas que HTML::Template en utilise (à vérifier).

(*) pour obtenir un fichier indépendant de la plateforme, il faut utiliser
'nstore'.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Paul Gaborit a utilisé son clavier pour écrire :

À (at) Fri, 01 Jul 2005 15:19:04 +0200,
"Jul" <julien@mesnews> écrivait (wrote):

Il s'agit de MySQL, en effet. Ce que je crains à ce sujet, c'est que le
serveur soit situé sur une autre machine du réseau local, ce qui
impliquerait déjà une légère augmentation du temps de réponse.

Sur un réseau local rapide (ce qui est certainement le cas actuellement),
vous ne verrez quasiment pas de différence entre une instance locale et une
instance distante... sauf bien sûr si le réseau est saturé.

Bon, alors ce ne doit pas venir de là, puisque c'est une structure
normalement bien développée (OVH).

On peut aussi faire de "l'IPC du pauvre" en utilisant le module Storable
pour stocker l'état d'une structure dans un fichier. J'utilise souvent
cette méthode avec bonheur.

C'est justement ce que je cherchais. Créer un dossier de cache pour
accueillir les compilations de modèles. Et n'arrivant pas à différencier
chaque type de cache manipulé par HTML::Template, j'ai cru que
IPC::SharedCache gérait aussi le cache sous forme de fichiers, soit qu'il
était nécessaire pour tout type d'utilisation du cache... Une chose que je
dois approfondir donc.

L'utilisation de 'Storable' est très simple. Pour stocker l'objet $obj :

store $obj, $filename; # (*)

Pour recréer cet objet :

$obj = retrieve $filename;

La seule limitiation c'est d'éventuelles références à du code dans
l'objet. Mais je ne pense pas que HTML::Template en utilise (à vérifier).

(*) pour obtenir un fichier indépendant de la plateforme, il faut utiliser
'nstore'.

...Effectivement, cette méthode marche :o) et est aussi utilisée par
HTML::Template (option 'file_cache', que je croyais devoir activer
uniquement en parallèle avec 'cache' ou 'shared_cache' --l'un
nécessitant une execution persistante et l'autre nécessitant
IPC::SharedCache)

Merci beaucoup pour cette aide (et au traducteur de la version
francaise de la doc du module, qui m'a permis moins de quiproquo) celà
devrait me permettre de gagner un peu en ressources... et encore un peu
de travail et de recherche devrait me permettre d'avoir un temps
d'execution très correct.

--
Jul... réapparru comme par enchantement