06-08-2013 05:24 PM - modifié 06-08-2013 05:26 PM
Pour mesurer la durée d'exécution d'un code (comparaison avec un autre code)
c'est toujours la même galère :
on place le dit code dans une boucle For, histoire de lui faire faire "10.000" loop
une structure séquence, 2 "tick count", des fils, une soustraction, un indicateur ...
voici un petit XControl qui facilite la chose.
on le dépose simplement à côté de la boucle For (ou même à l'intérieur), et il donne la durée, tout pareil.
à l'intérieur de ce XControl ... franchement, c'est tout bête.
comparaison entre la bonne vieille méthode et ce xctl
Résolu ! Accéder à la solution.
le 06-09-2013 03:19 PM
Salut, J’achète ! Bon je n’ai pas regardé le code mais l’idée est très intéressante. Je me pose des questions… il va falloir regarder le code
Bravo !!
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
le 06-09-2013 03:35 PM
bonjour Luc.
Je suis en train de "revoir" le code. Même résultat, juste "une autre façon".
Une des 2 structures case est inutile, et je vais utiliser une while au lieu d'une rétroaction.
Teste avec celui que j'ai posté (le résultat sera de toute façon le même)
et dis moi si les résultats obtenus sont ok.
le code ? bah, rien de bien chinois.
Le truc c'est que j'utilise la capacité du xcontrol à détecter le "run/stop" du vi.
le 06-09-2013 03:47 PM
OK quelle version de LV?
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
le 06-09-2013 03:59 PM
2012 de mon côté.
le 06-09-2013 04:22 PM
le 06-10-2013 02:25 AM
Hola,
J'approuve toujours les travaux de ceux qui essaient d'améliorer les techniques de benchmark dans LV, vu l'aspect pénible de la chose!
Cela dit, quelques remarques pour tirer le meilleur de ce XCtl :
- On a un peu l'impression qu'il ne fait rien jusqu'à la fin de l'exécution du VI. Pourrait-on imaginer une option du Xctl où l'on choisit une fréquence de rafraichissement pour voir le compteur s'incrémenter pendant l'exécution ?
- Comment qu'on fait si on veut benchmarker une partie du code, et pas son intégralité ? Ou juste un sous-VI ?
- Comment qu'on fait si on a plusieurs benchmarks indépendants dans un VI ?
Plus globalement, je ne crois pas qu'un XCtl soit la meilleur approche pour faire un benchmark. Un XCtl s'exécute en continu, même en éditant un bout de code, alors que le principe même du benchmark relève de l'exécution. A mon sens, un XNode (pour benchmarker un sous-VI), un quick drop ou un plugin RCF ont plus de sens 😃
J'avoue ne jamais avoir eu la patience de peaufiner ce XNode, mais bon, ça peut être une piste ! Il suffit d'ouvrir l'exemple Bench_Example ou de déposer le XNode sur un diagramme (sous réserver d'avoir un VI à benchmarker) pour le voir en action 🙂
Cdt,
Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.
06-10-2013 03:54 AM - modifié 06-10-2013 04:15 AM
Pourrait-on imaginer une option du Xctl où l'on choisit une fréquence de rafraichissement pour voir le compteur s'incrémenter pendant l'exécution ?
oui, c'est peut-être possible (pas certain) ... je regarderai à ça.
- Comment qu'on fait si on veut benchmarker une partie du code, et pas son intégralité ? Ou juste un sous-VI ?
- Comment qu'on fait si on a plusieurs benchmarks indépendants dans un VI ?
Ce n'est pas l'objectif de ce xcontrol ...
son objectif n'est pas d'être un outil "full options", mais uniquement de mesurer le temps d'execution du vi propriétaire.
Son utilité se place dans le cas d'un benchmark "global". (le cas typique est un bout de code dans une for)
mais ... si tu veux "un truc" tout propre et tout facile pour faire ça (voir le fichier joint)
C'est un polymorphique qui fonctionne "pas paire" et qui offre 4 paires possibles (bue, green, purple, red)
Ci-dessous une capture pour "montrer" l'utilisation.
Un XCtl s'exécute en continu, même en éditant un bout de code, alors que le principe même du benchmark relève de l'exécution.
Bien évidemment !
Le principe de ce xcontrol n'est pas de 'l'utiliser" en mode édition, mais bien d'utiliser ses propriétés en mode exécution.
En mode exécution, le xcontrol à la capacité de détecter le start/stop du vi, et donc de mesurer le temps entre les deux.
en ce qui concerne un éventuel xnode..
Technologie propre à NI, non portables ... les utilisateurs ne s'en servent pas.
EDIT:
merci pour le xnode, je regarderai ça.
il utilise des abilities que je n'ai jamais utilisés ... intéressant ça !
et il utilise (je pense, rapidement regardé) les dernières versions des abilities (GetTerms4 par exemple)
le 06-10-2013 07:08 AM
Sympa les FGV Timers par couleur :-] Mais c'est un outil statique qui va faire augmenter linéairement l'espace mémoire du VI appelant. Travaillons plutôt les DVR : une seule empreinte mémoire... 😃
Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.
06-10-2013 09:37 AM - modifié 06-10-2013 09:39 AM
les DVR ... ... je ne connais pas.
mais je ne resterai pas ignorant bien longtemps.
c'est du tout bon code tout ça ...
le xnode ... tout tout beau ... celui-là, sur mon écran, il n'est pas tombé dans un puits perdu.
et l'exemple de DVR non plus !
merci Eric, très très sympa d'avoir partagé ce genre de choses.
moi qui m'ennuyais un peu ... génial !
oui ... le vi timer polymorphique par couleurs, j'aime bien,
et ça fonctionne tip top. Mais "ça" mange de la mémoire ... hummm, ok, message reçu.