Discussion :

[vladvonjim]

Bonjour.
J'ai dans mon programme plusieurs fois un même bout de code écrit différemment, j'ai compris qu'il fallait simplifier le truc en harmonisant et passer le tout en private void mamethode() { mon code } que je j'appelle avec mamethode();

1° Esce que si mamethode() est appellé plusieurs fois en même temps ça peu poser souci ? ou il faut passer par un : this.mamethode() ou vérifier comme les backgroundworker qu'elle n'est pas occuper pour l'appeller ? if (!mamethode().IsBusy)
Question surement tres con mais je voudrait pas générer un bug.

2° pour ma methode() j'ai le choix entre 2 code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
if (a = b1)
{
    c = 1;
}
.
.
.
else if (a = b15)
{
    c = 15;
}

et le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
switch(a)
{
    case b1
    c = 1;
    break;
.
.
.
    case b15
    c = 15;
    break; //pas sur qu'y serve vraiment le dernier break
}

Le quel est le plus rapide à l’exécution ?

Globalement comment puis je vérifier les temps d’exécution entre 2 façon d'écrire du code car j'ai ce cas de figure un peu partout notamment avec des requête sur des pages xml.

Merci.

[Invité]

Tu peux appeler ta méthode au temps de fois que tu veux, et en même temps si veux...

Et pour la deuxième question je trouve la deuxième proposition plus claire, mais ça c'est une affaire de gout.

[Er3van]

Cela dépend de ce que tu appelles "plusieurs fois en même temps", et de si tu utilises des ressources critiques.
Si ça méthode se contente d'opérer sur les paramètres passés en entrée, aucun problème.

Pour ta deuxième question, es-tu bien sur de vouloir tester l'affectation? Ce n'est pas plutôt une comparaison que tu veux faire?

Pour ton switch, ça n'est possible que si b1 et b15 sont des constantes.

[spottt]

Bête remarque, mais bon :

Dans ton if (1ere méthode), j'imagine que tu veux comparer ta var a à une valeur, le double = s'impose donc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (a == valeur)

[vladvonjim]

Oui c'est du string (a, b1 à b15 et c) et (b1 à b15 et c) sont constant.
Donc B1 c'est "toto" b2 "tata" etc... jusqu’à B15...

Ce code vas me servir à 3 endroit différent.

Je récupère le string qui m’intéresse dans une cellule d'un datagridview, dans un domainupdown et dans le texte d'une balise xml je l'affecte dans chaque cas à mon : private string "a"; avec par exemple this.a = this.domainUpDown1.Text;

Vue que c'est dans des backgroundworker il n'est pas impossible qu'ils accèdent à mamethode() en même temps.

du coup le this.a risque de changer en cours de route non ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
if (this.a == "b1")
{
    c = "1";
}
.
.
.
else if (this.a == "b15")
{
    c = "15";
}

et le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
switch(this.a)
{
    case "b1"
    c = "1";
    break;
.
.
.
    case "b15"
    c = "15";
    break; //pas sur qu'y serve vraiment le dernier break
}

[spottt]

S'il y a risque d'accès à la méthode par différents threads, tu vas devoir implémenter un système de lock.

Ceci empêchera deux threads d'accéder à la même variable en même temps.

[vladvonjim]

ok vais regarder comment marche le lock.

Et sinon pour comparer les temps d’exécution de 2 bout de code faisant la même chose mais différent ?

[vladvonjim]

La méthode conseillée consiste à définir un objet private à verrouiller, ou une variable objet private static pour protéger des données communes à toutes les instances.

ça veux dire quoi ça ?
que si c'est codé comme ça y a pas de risque d'interaction de valeur de variable ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
Private string a;
private BackgroundWorker backgroundWorker1;
 
private void mamethode()
{
   switch(this.a)
   {
      case "b1"
      c = "1";
      break;
.
.
.
      case "b15"
      c = "15";
      break; //pas sur qu'y serve vraiment le dernier break
   }
}
 
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
   ...Du code...
   this.a = this.domainUpDown1.Text;
   mamethode();
   ...Du code...
}

[spottt]

Dans ton cas la différence sera de toute façon très (très très) faible.
Mais si ça peut être utile une autre fois, il y a pas mal de tools te permettant de tester cela.

Sinon, une classe .NET : StopWatch.

[spottt]

ça veux dire quoi ça ?
que si c'est codé comme ça y a pas de risque d'interaction de valeur de variable ?

Exact.

Un lock() autour d'une affectation, et tu es sûr qu'il n'y aura pas de conflit d'accès.

[Vimaire]

Bonjour, si tu passe a en paramètre de ta méthode, tu n'aura pas besoin de la locker, ta méthode n'utilisant plus de variables communes, mais une qui lui est propre, je te conseillerai un code de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
Private string a;
private BackgroundWorker backgroundWorker1;
 
private string mamethode(string a)
{
   if(a == "b1")
   {
      return "1";
   }
.
.
.
   if(a == "b15")
   {
      return "15"
   }
 
   // Pour notifier l'utilisateur que sa valeur n'est pas dans le range attribué
   thow new ArgumentException("Donnée invalide");
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
   ...Du code...
   this.c = mamethode(this.domainUpDown1.Text);
   ...Du code...
}

[vladvonjim]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
private string mamethode(string a)
 
     this.c = mamethode(this.domainUpDown1.Text);

en faisant comme ça il lance mamethode avec comme paramètre this.domainUpDown1.Text qu'il attribue automatiquement au "a" du (string a) et le return renvoyé se stocke dans "c".
Si je comprend bien ?

[Vimaire]

C'est ca, et vu qu'aucune des variables de la méthode elle même n'est partagée, elle seront propre au contexte d'exécution du thread, donc non partagées et donc, aucun intêret de les locker.

En revanche, si ta textbox est alimentée par l'utilisateur, tu devrais la griser lors de l'appel afin d'être sur qu'aucune donnée ne sera modifiée dedans :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
   ...Du code...
   domainUpDown1.Enabled = false;
   this.c = mamethode(this.domainUpDown1.Text);
   domainUpDown1.Enabled = true;
   ...Du code...
}

tu peux aussi utiliser une méthode abonnée à l'évènement RunWorkerCompleted pour dégriser la méthode, mais ca ne me semble pas vraiment nécessaire si tu n'as qu'une zone à griser.

ceci est bien sur valable si l'exécution de ton worker est déclenchée par l'utilisateur (via un clic ou autre évènement) si elle est déclenchée depuis un évènement du système, je te conseillerais de te récupérer la valeur depuis l'évènement système et la passer en paramètre au backgroundworker.