Conditionner le GoTo <line> : considérer le label comme une variable

Version imprimable

23/01/2019, 14h46
PeD012

Conditionner le GoTo <line> : considérer le label comme une variable
Bonjour,

est il possible de modifier la valeur d'un label et donc de conditionner un goto.

Exemple

Code:

&label = "test1"

et dans le code
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 ..... pppp pppp GoTo &label test1: xxxx xxxx xxxx test2: yyyy yyyy
Une autre fois, suivant l'une ou l'autre condition extérieure, il y aurait

Code:

&label = "test2"

Merci de votre avis implaccable ;)

Pierre

Note : cela existe dans d'autres langages, au moins en PL/I.
23/01/2019, 15h33
StringBuilder

Bonjour,

GOTO date de l'age d'or du Basic, notamment avec QBasic sous MS-DOS.

Pour des raisons proches de l'inexplicable, ce mot clé a été conservé dans certains langages modernes.

Mais une chose est certaine : il ne faut JAMAIS l'utiliser.

Les langages modernes que sont VB.NET (et même VB6 à l'époque de Windows 95) peuvent parfaitement s'en passer.
Et même à l'époque de QBasic, on pouvait déjà s'en passer d'ailleurs...

Repensez votre programme pour ne pas avoir à faire ces horribles GOTO.
23/01/2019, 15h51
PeD012

Merci pour la réponse, Stringbuilder.

Je ne vais pas entrer dans une guerre sur ce sujet. Votre programmation structurée peut certainement se passer des "goto" et vous faites bien.

Ma programmation l'a trouvé parfois utile, pas tout le temps loin de là.

Simplement aussi beaucoup de goto sont déguisés. Un call n'est finalement qu'un branch et un return, donc des goto.

J'ai la chance, et sans doute le désavantage, d'être un très, très ancien programmeur, ayant débuté en assembleur, où l'on ne compte plus les Goto.

Sans tomber dans les excès de la programmation spaghetti, ils peuvent être utiles.

Fin de la toute petite polémique qui n'en est pas une, j'assume mes faiblesses, croyez moi.

Mais pour revenir à ma question, la raison en est un substantiel potentiel gain de temps quand mon application doit traiter des centaines de milliers de records.

Bien à vous.

Pierre

Effectivement, au niveau machine, tout va se terminer à grand coup de JZ, JNZ, JE et JNE.

Seulement, justement parce qu'on ne fait pas d'assembleur mais de la programmation de haut niveau, il est plus lisible de programmer en utilisant les outils mis à disposition par l'outil plutôt que de tenter en utiliser d'autres.
Tu peux monter une formule 1 sur une planche à roulettes, elle va très bien avancer aussi…

Bref, tu as raison, il ne sert à rien d'entrer dans une discussion polémique sur le sujet… mais quand même !

Sinon, non, VB.NET ne permet pas de faire ce que tu cherches à faire.

En revanche, ce que tu cherches à faire ressemble s'y méprendre à un SELECT CASE, ou une série de IF, sauf si après "test1", "test2" doit toujours être exécuté, à ce moment ce sera un IF

On ne parle pas ici d'appeler des fonctions, mais bien de rester dans le même programme.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 &label = "test1" pppp pppp GoTo &label test1: xxxx xxxx xxxx test2: yyyy yyyy
Peut être transcrit : (si test1 et test2 s'excluent mutuellement)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 &label = "test1" pppp pppp select case &label case "test1" xxxx xxxx xxxx case "test2" yyyy yyyy end select
Si tu dois pouvoir passer de "test1" à "test2", alors ce sera plutôt :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 &label = "test1" pppp pppp if &label = "test1" or &label = "test2" then if &label = "test1" then xxxx xxxx xxxx end if yyyy yyyy end if
Désolé pour l'indentation

Niveau machine, tu auras juste un "goto" supplémentaire avec le IF. Pas de quoi fouetter un chat même si tu as des milliards de lignes à gérer.
D'autant qu'avec un langage tel que VB.NET je ne serais pas surpris une seconde que le GOTO provoque une batterie de tests complémentaires au moment de la compilation (et probablement de l'exécution) afin de blinder l'utilisation de variables locales/globales puisqu'on ne sait pas vraiment à l'avance où on va tomber.

23/01/2019, 16h28
PeD012

D'abord merci pour ton esprit. J'apprécie.

Pour ceci

Citation:

mais de la programmation de haut niveau, il est plus lisible de programmer en utilisant les outils mis à disposition par l'outil plutôt que de tenter en utiliser d'autres.

Je cherchais si VBNet admettait justement cette facilité. Je voulais donc bien ici profiter du langage et de tout ce qu'il offre :)

Le "Select case" ne résout en rien mon problème éventuel de performance mais que tu sembles balayer en disant

Citation:

Pas de quoi fouetter un chat même si tu as des milliards de lignes à gérer.

Je n'ai pas de référence quant à la performance donc je suis plutôt rassuré par ton avis.

OK je vais adapter mon programme ( et du mieux que je peux ;) )

Encore merci

Pierre
23/01/2019, 16h57
StringBuilder

Tout dépend de ce que fait ton programme.

Mais en règle générale, ce qui coûte cher, ce ne sont pas spécialement les aiguillages dans le programme, mais :
- Les IO
- La gestion mémoire

Tu parles ici de gérer un grand nombre de "Records".

J'imagine donc que ton programme va traiter des données contenues dans un fichier sur disque (latence de l'ordre de la milliseconde, qui peut vite augmenter si on ne travaille pas correctement avec un buffer pour accéder à plusieurs record par lecture/écriture).

Ensuite, qui dit Record dit aussi manipulation des données en mémoire une fois chargées : les affectations de chaînes de caractères, créations d'instances d'objets en mémoire, etc. sont de l'ordre de la dizaine / centaine de cycles CPU.

Le goto "unique" remplacer par 2 ou 3 en raison d'un select case ou des if, on reste à 1 ou 2 cycles CPU perdus : on est donc très loin en deçà.
Il ne faut pas oublier non plus que .NET optimise le code aussi bien à la compilation qu'à l'exécution. On peut donc se retrouver avec du code plus complexe de prime abord, mais plus performant au final.

A mon sens, quel que soit le besoin (mise à par si tu dois envoyer un astronaute sur Mars avec un processeur 8 bits à 3 MHz) la lisibilité du code doit toujours primer sur les "petites optimisation".
Ceci pour plusieurs raisons :
- Avoir un code lisible permet d'identifier plus facilement les incohérences algorithmiques. Ces erreurs sont en général la source de 90% des problèmes de performance (genre relire des informations sur le disque alors qu'on les a déjà en mémoire)
- Avoir un code lisible permet aussi de faire évoluer le code plus facilement. A nouveau, c'est généralement lorsqu'on met à jour le code qu'on provoque les plus grosses régression, en général car on n'a pas décelé l'impact négatif des modifications apportées

Après, il y a toujours des petites optimisations "à deux balles" qu'on peut garder sous le coude :
- Ne jamais utiliser "" mais String.Empty à la place
- Idem, toujours utiliser des constantes plutôt que des "nombres magiques"
- Toujours privilégier les opérations binaires aux opérations arythmétiques (mavar & 0x1) == 1 pour déterminer si un nombre est impair par exemple
- Ne jamais fait de concaténation de chaînes à l'aide de & mais toujours utiliser String.Concat, ou même un StringBuilder si les concaténations sont nombreuses
- Remplacer autant que possible les IF à l'intérieur de boucles par deux boucles à l'intérieur du IF/ELSE
- Etc.

Ces petites optimisations qui ne nuisent pas spécialement à la lecture (et souvent, bien au contraire) permettent d'apporter des gains significatifs lors des traitements intenses (notamment StringBuilder, les opérations binaires et surtout les IF dans les boucles).
Pour le reste, faire confiance à l'algorithme plutôt qu'à la syntaxe. De toute façon, le boulot du compilateur, c'est de réécrire ce qu'on a codé : tout ce qu'on risque de faire, c'est de passer à côté d'optimisations de ce dernier.

Pour illustrer ce que je viens de dire.

Certes, c'est pas du VB.NET, mais du C#. Vu que les deux reposent sur .NET ça ne change pour ainsi dire rien aux performances constatées, et je pense que le code reste suffisamment compréhensible.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
 
using System;
using System.Diagnostics;
using System.Text;
 
namespace TestGoto
{
    class Program
    {
        private const int NB_LOOPS = 100000;
 
        static void Main(string[] args)
        {
            int a = 0, b = 0;
            string sa = string.Empty, sb = string.Empty;
            StringBuilder sba = new StringBuilder(), sbb = new StringBuilder();
            Stopwatch sw = new Stopwatch();
 
            // Méthode "propre" sans code
            sw.Start();
            for (int i = 0; i < NB_LOOPS; ++i)
            {
                if ((i & 0x1) == 0 || i % 3 == 0) // Si i pair ou multiple de 3
                {
                    if ((i & 0x1) == 0) // Si i pair
                    {
                        a++;
                    }
                    a++;
                }
            }
            sw.Stop();
            Console.WriteLine($"Méthode 1 sans code : {sw.ElapsedTicks} ticks");
 
            // Méthode des goto sans code
            sw.Restart();
            for (int i = 0; i < NB_LOOPS; ++i)
            {
                if ((i & 0x1) == 0) goto multiplededeux; // Si i pair
                if (i % 3 == 0) goto multipledetrois; // Si i multiple de 3
                continue;
 
                multiplededeux: // i pair
                b++;
                multipledetrois: // i multiple de 3 ou pair
                b++;
            }
            sw.Stop();
            Console.WriteLine($"Méthode 2 sans code : {sw.ElapsedTicks} ticks");
 
            // Méthode "propre" avec du code sale
            sw.Restart();
            for (int i = 0; i < NB_LOOPS; ++i)
            {
                if ((i & 0x1) == 0 || i % 3 == 0) // Si i pair ou multiple de 3
                {
                    if ((i & 0x1) == 0) // Si i pair
                    {
                        a++;
                    }
                    a++;
                    sa += ".";
                }
            }
            sw.Stop();
            Console.WriteLine($"Méthode 1 avec code sale : {sw.ElapsedTicks} ticks");
 
            // Méthode des goto avec du code sale
            sw.Restart();
            for (int i = 0; i < NB_LOOPS; ++i)
            {
                if ((i & 0x1) == 0) goto multiplededeux; // Si i pair
                if (i % 3 == 0) goto multipledetrois; // Si i multiple de 3
                continue;
 
                multiplededeux: // i pair
                b++;
                multipledetrois: // i multiple de 3 ou pair
                b++;
                sb += ".";
            }
            sw.Stop();
            Console.WriteLine($"Méthode 2 avec code sale : {sw.ElapsedTicks} ticks");
 
            // Méthode "propre" avec du code propre
            sw.Restart();
            for (int i = 0; i < NB_LOOPS; ++i)
            {
                if ((i & 0x1) == 0 || i % 3 == 0) // Si i pair ou multiple de 3
                {
                    if ((i & 0x1) == 0) // Si i pair
                    {
                        a++;
                    }
                    a++;
                    sba.Append('.');
                }
            }
            sw.Stop();
            Console.WriteLine($"Méthode 1 avec code propre : {sw.ElapsedTicks} ticks");
 
            // Méthode des goto avec du code propre
            sw.Restart();
            for (int i = 0; i < NB_LOOPS; ++i)
            {
                if ((i & 0x1) == 0) goto multiplededeux; // Si i pair
                if (i % 3 == 0) goto multipledetrois; // Si i multiple de 3
                continue;
 
                multiplededeux: // i pair
                b++;
                multipledetrois: // i multiple de 3 ou pair
                b++;
                sbb.Append('.');
            }
            sw.Stop();
            Console.WriteLine($"Méthode 2 avec code propre : {sw.ElapsedTicks} ticks");
 
            Console.ReadKey();
        }
    }
}

Voici ce que ça donne sur mon PC (une vieille brouette) en mode DEBUG :

Code:

1
2
3
4
5
6
7
 
Méthode 1 sans code : 1395 ticks
Méthode 2 sans code : 1356 ticks
Méthode 1 avec code sale : 1905167 ticks
Méthode 2 avec code sale : 1803239 ticks
Méthode 1 avec code propre : 1939 ticks
Méthode 2 avec code propre : 1946 ticks

On remarque que la syntaxe avec GOTO est légèrement plus rapide.
En moyenne, j'arrive à 10% de gain, ce qui n'est pas tout à fait négligeable, et tend à contredire ce que j'ai dit plus haut.

En revanche, on voit clairement que dès qu'on commence à effectuer du code (ici, je me contente de rajouter "." à une chaîne de caractère à chaque fois que i est multiple de 2 ou 3) les performances tendent à donner raison à ma remarque quant aux optimisations de code... Le code avec StringBuilder est... 1000 plus rapide que le code avec concaténation de chaîne !
=> S'il y a des optimisations à faire, c'est donc avant tout dans les traitements, plus que dans l'aiguillage.

Par curiosité, j'ai aussi compilé en mode RELEASE.
Et là, ce que je disais tout à l'heure à propos du compilateur et runtime qui de toute façon optimisent le code qu'on a écrit devient vrai :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
C:\Users\admin\source\repos\TestGoto\TestGoto\bin\Release\netcoreapp2.1>dotnet TestGoto.dll
Méthode 1 sans code : 365 ticks
Méthode 2 sans code : 418 ticks
Méthode 1 avec code sale : 1574060 ticks
Méthode 2 avec code sale : 1571454 ticks
Méthode 1 avec code propre : 1052 ticks
Méthode 2 avec code propre : 949 ticks
s
C:\Users\admin\source\repos\TestGoto\TestGoto\bin\Release\netcoreapp2.1>dotnet TestGoto.dll
Méthode 1 sans code : 375 ticks
Méthode 2 sans code : 406 ticks
Méthode 1 avec code sale : 1575818 ticks
Méthode 2 avec code sale : 1557730 ticks
Méthode 1 avec code propre : 900 ticks
Méthode 2 avec code propre : 957 ticks
s
C:\Users\admin\source\repos\TestGoto\TestGoto\bin\Release\netcoreapp2.1>dotnet TestGoto.dll
Méthode 1 sans code : 361 ticks
Méthode 2 sans code : 432 ticks
Méthode 1 avec code sale : 1586549 ticks
Méthode 2 avec code sale : 1568836 ticks
Méthode 1 avec code propre : 902 ticks
Méthode 2 avec code propre : 935 ticks
s
C:\Users\admin\source\repos\TestGoto\TestGoto\bin\Release\netcoreapp2.1>

Le code sans les goto est au final plus rapide, car le compilateur et le runtime ont probablement mieux compris comment l'optimiser.

23/01/2019, 17h34
PeD012

Ta réponse me laisse perplexe, non pas quant à la pertinence de ton avis, mais parce qu'il suscite des interrogations chez moi.

Et comme il n'est jamais trop tard pour apprendre, et que cela est source de satisfactions, y a t il ici développez.com sur le sujet .NET des guides de performances
( je vais voir mais si on peut me donner une indication )
ou même des bouquins sur le sujet ( et oui je lis encore :-) )?
Ou est ce part de votre formation initiale?...….. ou par expérience.

Bonne soirée

==================

je viens de voir ton dernier message. J'examine cela. Merci pour ces tests et le temps passé.
23/01/2019, 17h38
StringBuilder

Citation:

Envoyé par PeD012

Ta réponse me laisse perplexe, non pas quant à la pertinence de ton avis, mais parce qu'il suscite des interrogations chez moi.

Si tu prends le temps de lire mon petit benchmark, tu verras que c'est plus qu'un avis ;)

Sinon, j'ai tout appris sur le tas. Moi aussi je suis un vieux de la vieille, j'ai commencé en faisant du Logo sur Commodore 64 ;)

Je suis loin d'être un expert, en revanche j'ai tendance à ne pas oublier quand l'exemple contredit mes convictions ;)

Pour ce qui est d'un "guide" pour avoir de bonnes performances, je n'en ai pas connaissance.
Sur DVP c'est assez pauvre sur le sujet (en revanche on peu aisément discuter et tomber sur des personnes qui prennent le temps d'expliquer).
Sur StackOverflow, on trouve beaucoup de sujet sur les performances, généralement très complets. Par contre il faut savoir ce qu'on cherche (car poser une question sur ce forum s'avère généralement la première et la dernière intervention qu'on fait étant donné leur système de points)
23/01/2019, 20h18
Pol63

pour apprendre sur comment faire des choses performantes il faut mesurer et comprendre comment fonctionne .net en bas niveau

pour mesurer il y a system.diagnostics.Stopwatch (chronomètre)
attention : la 1ère mesure est potentiellement fausse (inclus le temps de compilation finale du code), donc c'est à faire plusieurs fois pour trouver une moyenne sur les quelques derniers tests
pour des petites choses il faut souvent les faire plusieurs fois pour avoir des valeurs utiles (en dessous de 1ms ce n'est pas précis)
ensuite on peut essayer plusieurs manières de faire pour comparer et trouver ou comprendre ce qui prend du temps dans les versions longues, ainsi avec le temps on sait quoi utiliser et quand

pour comprendre comment fonctionne .net il y a plein de sources, récemment un article est passé ici sur le fonctionnement du garbage collector, sur Microsoft Docs (anciennement MSDN) il y a aussi des articles complets
on peut se renseigner sur la gestion de la mémoire (stack/heap), ByVal/ByRef et tout ce qui va avec, et regarder le code source du Framework (dispo car open source)

sinon concernant le goto je confirme que c'est dommage de l'utiliser en .net
un code .net est fait pour être structuré en orienté objet, donc normalement c'est rare d'avoir plus de 50 lignes de code dans une méthode, donc souvent moins, et un GOTO ne sert à rien dans ce contexte
pour arriver à faire peu de code au lieu de plein il faut donc maitriser l'héritage, les interfaces, le polymorphisme, action/func/lambda, linq, les différents types de collections etc...
23/01/2019, 23h14
PeD012

Pol63,

Je ne puis dire que "merci" pour ces bonnes considérations , mais un merci sincère ;) ……………. et retourner à un peu de recherche de lecture et expérience.

Bonne soirée

Pierre
24/01/2019, 07h52
Pol63

Sachant que ce n'est pas toujours utile ou prioritaire de faire du code performant.
Des fois c'est le temps développement qu'on souhaite améliorer (la aussi la poo apporte son lot de possibilités), une méthode qui va être appelée une fois par heure qu'elle prenne 2ms ou 200 ça ne change pas forcément grand chose.
Aussi il est courant de faire une passe de développement puis de mesurer certaines choses ou constater ce qui prend du temps pour décider qu'elle partie on va tenter d'améliorer.
Pour ça le forum peut être pratique, tu peux poster un bout de code (éventuellement transformé pour qu'on voit juste le principe de base) et les pros pourront t'expliquer comment mieux faire (si c'est possible) ce qui permet d'apprendre des manières de faire ou des classes qu'on ne connaît pas.
Ton besoin de goto si tu nous expliques le pourquoi on pourra peut être te dire comment t'en passer.