Une variable objet pour les contrôler tous?

Bonjour,

:arrow: Je suis en charge d’une application qui possède beaucoup de variables process (700 tableaux et 3000 variables) et qui, dans son fonctionnement, est très multiprocess (beaucoup de process sont créés, terminés, d’autres ont une longue durée de vie…).
Toutes ces variables ne sont bien évidemment pas utilisées dans chaque process créé.

:?: Pensez-vous qu’il soit judicieux d’imaginer supprimer toutes ces variables process pour les rassembler (au besoin pour chaque process) dans une seule variable process de type objet ?

Merci d’avance pour vos réponses !! :pray:

: Serge HAROUTUNIAN

Pensez-vous qu’il soit judicieux d’imaginer supprimer toutes ces
variables process pour les rassembler (au besoin pour chaque process)
dans une seule variable process de type objet ?
Cet objet ne serait il pas le…https://doc.4d.com/4Dv17/4D/17.3/Storage.301-4621577.fr.htmlstorage>?

: Bertrand SOUBEYRAND

Cet objet ne serait il pas
le…https://doc.4d.com/4Dv17/4D/17.3/Storage.301-4621577.fr.htmlsto
age>?
Il s’agit de remplacer des variables process.

Bonjour Bertrand,

Non le but n’est pas de partager ces variables entre les process. Elles restent d’usages indépendants (ont des valeurs différentes) d’un process à l’autre.

Je peux me tromper mais je pense qu’outre le nombre c’est également le poids de ces variables qui sont copiées pour chacun de tes process. Donc, vouloir diminuer le nombre c’est bien, mais si au final c’est pour garder le même poids en mémoire dans la pile de ton process je ne pense pas que tu vas y gagner. Le Storage c’est plus pour des variables globales, et ça a un coût supplémentaire d’utilisation.

Je serais toi je commencerais par essayer de remplacer les variables process par des variables locales là où c’est possible. C’est long et fastidieux à faire mais c’est plus sûr.

J’étais dans le même cas que toi, j’ai diminué progressivement l’utilisation des variables process. Là où c’est plus embêtant, c’est pour les impressions, j’ai des impressions d’états fait mains de l’époque avec une variable process par info; c’est compliqué à remplacer. D’ailleurs, si quelqu’un à une astuce :?:

Bonjour Manuel,

En effet l’allocation mémoire dédiée à toutes ces variables process et générée pour chaque création de process est très lourd !

Mais justement, chacun des process créé est très loin d’utiliser toutes ces 3700 variables et tableaux. Le but serait de rajouter uniquement les élément à l’objet les éléments nécessaire au fur et à mesure du besoin. Il ne serait donc alloué moins d’espace au final; mais au lieu d’avoir une seule grosse allocation en début de process, il y en aurait plusieurs petites au fil de la vie de chaque process.
Mais en fin de process nous finirions systématiquement avec moins d’allocation totale.

C’est mon point de vue, et j’aimerais voir des critiques là-dessus car je ne vois pas trop de défaut à cette solution.

: Serge HAROUTUNIAN

:?: Pensez-vous qu’il soit judicieux d’imaginer supprimer toutes ces
variables process pour les rassembler (au besoin pour chaque process)
dans une seule variable process de type objet ?
Je verrais surtout ça comme une bonne occasion de faire le ménage, 3700 ça fait quand même beaucoup pour caractériser des process, fussent-ils très différents.

Bonjour Arnaud,

Je suis bien d’accord, c’est un travail de Titan et de fourmis à la fois. J’y travail régulièrement mais cela parait sans fin. Lorsque j’ai hérité du logiciel il y avait près de 5000 variables et tableaux process…

Ta solution est malgré tout un tourne-autour, donc la meilleure chose c’est quand même de n’utiliser une variable que le temps nécessaire d’où l’utilisation de variables locales le plus possible.

Garde à l’esprit, que c’est le poids en mémoire qui pose problème, car il sera multiplié par le nombre de process. C’est encore plus vrai sur le serveur. Et multiplié par le nombre de clients connectés.

Si tu fais ce travail tu vas être quand même obligé de revoir ton code donc je ne sais pas si tu seras gagnant en termes de temps de mise en œuvre ?

Bonjour Manuel,

À la base ce serait l’idéal en effet; mais quand je regarde le code, bien souvent des variables sont initialisées en fin de hiérarchie d’appels de fonctions, puis utilisées bien plus tard après être remonté dans cette hiérarchie (voir après avoir fait du yoyo…), parfois même après plusieurs formulaires utilisés. Transporter autant de variables dans chaque fonction génère aussi beaucoup de petites allocations mémoires, même en passant pas des paramètres de type pointeurs (qui n’est pas recommandé par 4D avec des variables locales).

L’usage de cet objet unique me permettrait de transporter l’information utile le temps nécessaire et rendre la mémoire (OB REMOVE) une fois qu’elle n’a plus besoin de vivre; L’allocation mémoire n’est ainsi faite qu’une seule fois et son transport entre fonctions est grandement facilité.

Le passage des infos par un objet c’est bien, mais ce n’est pas utilisable partout. Autant nous, on peut facilement l’utiliser, autant pour les utilisateurs finaux ce n’est pas aussi simple de construire un objet. Je pense à des API de méthodes utilisées dans des états semi-auto, etc.

Mais, ce que tu décris va demander beaucoup de réécritures ; donc, de toute façon, je ne vois pas où tu vas gagner en temps de mise en œuvre :frowning:

Cela revient à revoir entièrement son code.

Et dans ce cas, les bonnes pratiques ben tu peux les mettre en œuvre.

Dans l’optique d’une optimisation de l’occupation mémoire seulement, ça peut être une bonne solution pour les variables process qui ne sont pas utilisées en tant que variable d’objet de formulaire. Ca mérite peut-être un bench sur l’impact que vont avoir ces multiples allocations/désallocations sur la performance (je ne sais pas si 4D alloue d’un seul bloc toute la mémoire nécessaire à toutes les variables process, ou s’il les alloue une par une. Dans le premier cas tu risques de perdre du temps à faire des allocations multiples. Dans le second cas, l’allocation d’une propriété est peut-être plus longue que celle d’une variable process. Mais si tu n’as pas besoin des 3700 variables à chaque process, tu devrais y gagner).

Attention cependant aux pièges de la non-déclaration : tu dois pouvoir isoler avec certitude le cycle de vie réel de la totalité des variables process qui sont utilisées individuellement pour chaque process, pour n’initialiser que les propriétés concernées. Si tu fais mal cette étape, tu vas te retrouver à devoir tout re-déclarer (donc c’est inutile), ou à oublier des déclarations (ce qui va générer des plantages). Le fait que certaines variables soient initialisées “en fin de hiérarchie d’appels de fonctions” risque de ne pas t’aider. Si tu travailles en compilé, n’oublies pas que les variables process sont systématiquement connues dès le lancement du process. Ce ne sera pas le cas des propriétés de ton objet. Il n’est pas impossible que ton appli contienne des parties dans lesquels les développeurs d’avant se soient basés sur le fait que telle variable est forcément soit déjà affectée, soit initialisée d’office à 0, pour écrire leur code.

Attention aussi aux éventuels appels à pointeur vers(“tonObjet.taVariableProcess”) qui ne passera pas.

La non-recommandation par 4D de pointeurs avec des variables locales, c’est pour éviter de se retrouver avec un pointeur qui pointe vers une variable locale à une fonction après avoir appelé cette fonction (et donc qui pointe sur un espace désalloué) ? Ou il y a une autre raison ? Si c’est le cas, je suis preneur.

Dans mon application, j’ai, comme toi, des milliers de variables qui se reproduisent toutes seules à chaque process lancé.
Par simplicité, je lance l’initialisation de toutes les variables à la création d’un nouveau process (Olivier, bouches-toi les oreilles !).
Mon application comporte plusieurs modules et est basée sur un fonctionnement ressemblant au mode utilisation directe d’autrefois.

Agir sur les variables ne peut se faire sans agir sur les process :

  • utiliser les variables de formulaire
  • utiliser le ‘Form’, ce qui rejoint ton idée d’objet global
  • grâce à ce ‘Form’, supprimer aussi beaucoup de variables locales
  • reconcevoir les process ; au lieu d’afficher toutes les tables une par une, je crée des formulaires sur des processus plus globaux qui me présente les informations soit dans des listboxes, soit dans des variables de formulaire logées dans le ‘Form’
  • le ‘Form’ peut être construit par morceaux à partir d’objets et n’a pas besoin de tout stocker ; les morceaux ne servant pas peuvent aussi être effacés.
    Les variables globales ou interprofessionnelles vont devenir obsolètes et pourront être supprimées.

En conclusion, c’est la remise en cause de la conception de l’application qui permettra la suppression des variables plutôt que la seule utilisation massive d’objets.

: Nicolas BERTHELON

La non-recommandation par 4D de pointeurs avec des variables locales,
c’est pour éviter de se retrouver avec un pointeur qui pointe vers
une variable locale à une fonction après avoir appelé cette fonction
(et donc qui pointe sur un espace désalloué) ? Ou il y a une autre
raison ? Si c’est le cas, je suis preneur.
Oui, moi aussi je n’ai pas compris ; il doit y avoir une confusion.

L’utilisation de variables locales ne pose aucun problème.

Form reprend l’objet passé en paramètre de dialogue, donc en sortie de dialogue, tu vas te retrouver avec un objet bourré d’infos qui ne te serviront peut-être plus.

Juste pour préciser que Form et variables locales sont 2 choses distinctes.

De même, si tu dis que les variables interprocess seront obsolètes (par rapport à l’utilisation du Storage), tu vas te faire taper sur les doigts…

C’est 2 choses qui cohabiteront et qui n’ont pas forcément la même utilité.

Ce qui est discuté ici c’est SURTOUT les variables process qui elles posent réellement un véritable problème.

le post de TM sur https://forums.4d.com/Post/FR/32364673/1/32368662#32368662les objets versus paire de tableaux>

Ça peut donner des idées