question existentielle sur le compilateur de LabView

[rapace51]

Bonjour à toutes et tous,

je réalise de gros projet sous LabView avec de multiples sous-vi. Je test chacun de mes sous-vi dans tous les cas possibles et rajoute donc souvent des indicateurs à certains point de mes sous-vi, ces indicateurs ne sortent pas de ces sous_vi (pas liés à desz connecteurs de sortie) et ne servent pas dans le programme principal. Ma question est de savoir si le fait de laisser ces indicateurs dans les sous-vi peuvent ralentir le programme principal ou alors est ce que le compilateur est assez intélligent pour les enlever à la compilation ?

Merci de vos indications

PS: je sais que je pourrais utiliser des sondes à la place mais c'est souvent plus pratique pour moi au niveau de l'affichage d'avoir des indicateurs lors des tests.

[JimChretz]

LabVIEW laisse les indicateurs, on ne souhaite pas que LabVIEW les enlève!

[Desruelle_luc]

Bonjour la réponse est un peu plus complexe que oui ou non.

La réponse va dépendre en "source" ou "exe"?

je me permets de développer...

[Desruelle_luc]

Comme tu l’écris LabVIEW est un langage compilé.

Extrait du livre "LabVIEW : programmation et applications"

La compilation signifie que le code G que vous écrivez est traduit en code machine et qu'il est ensuite exécuté directement par l'ordinateur.La compilation du code est un processus aussi transparent pour l’utilisateur que très complexe. Composé de deux compilateurs, DFIR qui est open source et LLVM propriétaire de National Instruments. Ces deux compilateurs travaillent pour nous en optimisant fortement le code pour améliorer la gestion mémoire et les performances d'exécution. Voici les principales « tâches » effectuées lors de la compilation :

1. La « Propagation de type » qui permet de détecter et reporter les erreurs de programmation au niveau du langage LabVIEW. Elle est responsable de la « flèche brisée » lorsqu’un code n’est pas fonctionnel ;
2. « Inplacer » qui identifie les allocations de mémoire réutilisable, ce qui évite des copies superflues de données et, par conséquent, accélère les performances d'exécution ;
3. « Clumper » qui identifie le parallélisme dans le diagramme et regroupe les fonctions en blocs capables de s'exécuter en parallèle ;
4. Le support pour générer le code pour les différentes cibles logicielles et matérielles.

pour simplifier : oui le compilateur va fortement optimiser ton code. Mais à ta question précise, le processus de compilation supprime des constantes, du code "mort", optimise le parallélisme... mais il ne supprime pas les indicateurs des VI's.

Si tu veux plus d'infos sur le compilateur, j'ai quelques infos sur mon blog LabVIEW Compiler, l'histoire du compilateur LabVIEW, compiler le code G

[Desruelle_luc]

mais car il y a toujours un mais....

Extrait du livre "LabVIEW : programmation et applications" chapitre 3, aborde la programmation avancée en LabVIEW en définissant des techniques et architectures permettant au code d être maintenable, évolutif et performant.

Mais la question est "environnement de développement ou Exécution ?"

En général, la finalité d’un développement est de créer un exécutable autonome, un « .exe ». Il fonctionne alors dans l’environnement d’exécution ou RunTime.

[...]

L’Application Builder va transformer l’ensemble des VIs du code source en un fichier binaire.

[...]

Faire fonctionner un exécutable est plus performant que l’utilisation du même code dans l’environnement de développement, et cela même s’il est compilé. Sans entrer dans les détails, nous évoquerons l’argument important que dans l’exécutable, les « face-avant » sont supprimées, sauf évidemment pour les boîtes de dialogue et le programme principal. Cela permet de limiter les mises à jour graphiques qui peuvent monopoliser énormément de ressources.

[Desruelle_luc]

Donc la réponse à ta question est différente si tu restes en code source (développement) ou si tu réalises un exe (exécution)

Les mises à jour graphiques, qui sont réalisées dans le thread UI, sont consommatrices de ressource.

si tu veux des infos sur la gestion des données... Darwin applied to LabVIEW:  The evolution of the data management

En source, si la « face-avant » (d'un sous-vi) n’a pas été « ouverte, il y a une influence minime. Par contre, si l’IHM est chargée en mémoire, si tu as un graphique de 60000 points avec 10 courbes…

par contre si le sous-vi n’est pas visible, lors de la génération de l’exécutable, la face-avant n’est pas conservée, donc pas de mise à jour graphique des indicateurs.

A+

[JimChretz]

ça ne dépend nullement d'être en développement ou exe.

On pourrait toujours faire du code qui dynamiquement irait obtenir la référence de n'importe quel VI en mémoire, et de ses contrôles/indicateurs. De cette référence on peut aller chercher la valeur ou n'importe quelle propriété, Position, etc. Donc pour que ceci soit possible, on ne souhaite surtout pas que le compilateur prenne la décision d'éliminer des contrôles, tout ce qui est codé sera exécuté. Point à la ligne.

Donc la réponse à ta question est un NON clair et net, sans nuance.

[rapace51]

Merci à tous pour vos éléments de réponse.

Le but de mes programmes étant un executable pour de l'embarqué, et pour optimiser la rapidité du code je comprends qu'il faut enlever tous les indicateurs superflus.

Merci.

Cordialement.

PS : il manque une section  qui résumerait toutes les bonnes pratiques pour realiser le code le plus rapide qui soit.

[Desruelle_luc]

bonjour à tous,

tu es sûr de toi? que cela ne dépend pas d'être en code source ou executable?

---

JimChretz a écrit :

ça ne dépend nullement d'être en développement ou exe.

On pourrait toujours faire du code qui dynamiquement irait obtenir la référence de n'importe quel VI en mémoire, et de ses contrôles/indicateurs. De cette référence on peut aller chercher la valeur ou n'importe quelle propriété, Position, etc. Donc pour que ceci soit possible, on ne souhaite surtout pas que le compilateur prenne la décision d'éliminer des contrôles, tout ce qui est codé sera exécuté. Point à la ligne.

Donc la réponse à ta question est un NON clair et net, sans nuance.

---

[Desruelle_luc]

Nous sommes d'accord, qu'un VI LabVIEW comporte quatre composants :

1.       La Face-avant ;

2.       Le Diagramme ;

3.       Le Code, qui est le diagramme compilé en code machine ;

4.       Les Données : valeurs des commandes et des indicateurs, valeurs par défaut, valeurs des constantes du diagramme, etc.

Comme j'ai noté dans mon message : [...] dans un exécutable, les « face-avant » sont supprimées, sauf évidemment pour les boîtes de dialogue et le programme principal.

Pour illustrer ma réponse, je fais (rapidment) un code avec : un code Main (le Top Level) qui appelle un sous-VI.

Je fais un projet, et je prépare la génération d'un exe.

Si je regarde les propriétés de l'exe, le sous-VI n'aura pas de front panel (de face-avant)