Discussion :

[Eric_M]

Bonjour à tous,

Connaissez-vous des trucs pour améliorer la vitesse d'exécution de son
programme (autre que supprimer les lignes de codes inutiles)?

Merci

[cinemania]

ba le code inutile ...

non mais sérieusement, tu crois qu'on peut te répondre comme cela ?
les raisons d'un code lent sont multiples.

mauvaise utilisation des différentes méthodes du framework.
la mauvaise utilisation des requêtes Linq ou des méthodes d'extensions, sont souvent à la source de divers problèmes de performances.

ensuite à part des idioties genre if b = true then qui ajoute un test inutile ... qui au passage n'est pas supprimé par le compilateur vb.net mais seulement à la compilation JIT pendant l'exécution, il ne demeure pas grand chose...

l'algorithmique... ce mot barbare...

en effet parfois, il est nécessaire de réécrire totalement des pans entiers de code car l'algorithme utilisé est une catastrophe en terme de performances.

quand à l'idée reçut qui fait penser qu'on peut allouer autant de ram qu'on veut pour accélérer un traitement, il faut également l'oublier... l'instanciation n'est pas un acte gratuit, et massivement repété, il peut devenir plus problématique que salvateur, et plomber encore plus les performances que le traitement lui même...
après c'est une question d'équilibre.

Sans plus de détails, là j'avoue que je vois pas trop quoi te dire...

si tu nous disais exactement ce qu'il en est ? non parce que là à part énoncer des platitudes... on va pas aller bien loin.

[Eric_M]

D'accord, je comprend.

Donc, à part ça, il y a pas grand chose à faire.

J'ai une dernière question: Si j'ai plain de variable à déclaré, est-ce (un peu) plus rapide à exécuter si leurs déclarations sont fusionnées?

Ex.:

Code :

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

1
2
Dim asd, dsa as Boolean
Dim fgh, hgf as String

À la place de

Code :

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

1
2
3
4
Dim asd as Boolean
Dim fgh as String
Dim dsa as Boolean
Dim hgf as String

[methylene]

Bonne question, je dirais à priori que oui.

Le programme étant exécuté ligne par ligne, s'il y a moins de lignes cela doit être plus rapide (en terme de déclaration), surtout s'il s'agit du même type d'opérations (c'est à dire que pour déclaré 2 string, le sytème va faire appelle au même type de ressource).

Mais bon je dis peut-être une connerie.

Par contre :

Code :

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

1
2
3
4
Dim asd as Boolean
Dim dsa as Boolean
Dim fgh as String
Dim hgf as String

est sensiblement aussi rapide que :

Code :

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

1
2
Dim asd, dsa as Boolean
Dim fgh, hgf as String

Mais bon on parle en terme de nanosecondes, voir pico donc ...

[Pol63]

mauvaise utilisation des différentes méthodes du framework.
la mauvaise utilisation des requêtes Linq ou des méthodes d'extensions, sont souvent à la source de divers problèmes de performances.

en quoi les méthodes d'extension peuvent causer des ralentissements ?

ensuite à part des idioties genre if b = true then qui ajoute un test inutile ...

si tu veux dire que if b serait plus performant que if b = true je ne comprends pas trop, c'est la même chose donc pour moi pas de différrence

quand à l'idée reçut qui fait penser qu'on peut allouer autant de ram qu'on veut pour accélérer un traitement, il faut également l'oublier... l'instanciation n'est pas un acte gratuit, et massivement repété, il peut devenir plus problématique que salvateur, et plomber encore plus les performances que le traitement lui même...

là pas d'accord du tout, une instanciation ca ne prend rien comme temps, on instancies de dizaines de milliers de variables au démarrage de notre appli, qui démarre instantanément
seules les classes graphiques ou non managées peuvent causer des soucis de perf à trop en utiliser je pense

Bonne question, je dirais à priori que oui.

Le programme étant exécuté ligne par ligne, s'il y a moins de lignes cela doit être plus rapide (en terme de déclaration), surtout s'il s'agit du même type d'opérations (c'est à dire que pour déclaré 2 string, le sytème va faire appelle au même type de ressource).

Mais bon je dis peut-être une connerie.

oui mais c'est pas grave

le programme est bien exécuté ligne par ligne, mais il y a 2 compilations entre ton code et le code exécuté
une ligne de ton programme peut etre des dizaines de lignes au niveau de l'exécution finale
donc l'ide (vs) te permet de mettre des choses sur la meme ligne, il te fais avancer le pas à pas ligne par ligne, mais c'est tout


pour gagner du temps dans un programme il faut déjà trouver les endroits qui prennent du temps, pour ca le system.diagnostics.stopwatch (chronomètre) peut etre utile
ensuite selon ce qu'il y a dans la partie lente on peut voir ce qu'il y a à faire
les sources de lenteur les plus courantes sont la gestion d'interfarces avec beaucoup de controles en windows forms et l'accès à une base de données
après pour des algorithmes, il y a souvent des tas de manières de les écrire, et le mieux si on sait que ca va etre utilisé souvent c'est d'en tester au moins deux pour garder la plus rapide


à savoir aussi un programme .net est compilé à chaque exécution, et ca ca plombe les perfs du premier appel (genre des sub de 10ms passent à 500ms)
en fait les classes (ou membres peut etre, je sais pas trop comment ca procède) sont compilés au fur et à mesure de leur utilisation
pour ca on peut faire un peu de multithreading et préappeler des trucs en arrière plan
(d'ailleurs le multithreading j'en ai pas parler, mais si t'as une boucle de 100k traitements indépendant, et 2 cores sur ton pc tu peux aller presque 2x plus vite avec deux threads)
ou sinon ngen.exe permet de figer une compilation sur le poste de destination afin de régler le problème

[cinemania]

Pol63 ce qui est pareil pour toi ne l'est pas pour le compilateur

if b
et
if b = true

sont 2 choses distinctes...
en effet, dans la première le if évalue directement la variable b et donc son résultat.
dans la seconde, il n'évalue pas b directement, au lieu de cela il évalue une égalité entre b et true, et ensuite il évalue le résultat, ce qui fait 2 opérations au lieu d'une (en réalité beaucoup plus que 2 opérations en msil)... Alors certes ce sont des nanosecondes mais tout de même.
ce genre de chose dans des sections critiques peut plomber les performances... certes peu de temps car une fois compilé en natif par le JIT les doubles tests sont supprimés, mais avant non et selon la complexité du programme, une telle boucle peut s'exécuter pas mal de fois avant d'être transformée.

ensuite effectivement comme l'a dit Pol63 le fait de faire

Code :

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

1
2
3
 
Dim asd, dsa as Boolean
Dim fgh, hgf as String

est strictement identique une fois compilé en CIL à

Code :

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

1
2
3
4
5
 
Dim asd as Boolean
Dim dsa as Boolean
Dim fgh as String
Dim hgf as String

ainsi une écriture C# :

Code :

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

1
2
 
asd = dsa = true;

est équivalent une fois compilé en MSIL à

Code :

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

1
2
3
 
asd = true;
dsa = true;

Pol63 pour répondre à ta question sur les méthodes d'extensions, j'ai bien parlé d'une mauvaise utilisation...
car celles-ci masquent souvent qu'il y a un parcours d'énumération derrière pour une bonne partie de ces opérations.
Quand on est parfaitement conscient de ce que l'on écrit, les méthodes d'extensions et les requêtes Linq sont géniales.

Un autre problème de lenteur peut se traduire par une utilisation d'une structure de données non adaptée au problème.

Le multithreading peut également améliorer les performances.
D'autres choses peuvent améliorer les performances,
Comme la mémoization et la mise en cache (attention à ne pas en abuser non plus pour ne pas tomber dans le travers que j'ai déjà cité)
Eviter comme la peste les instanciations et les appels, de propriétés ou méthodes, par la Reflexion... il n'y a pas mieux pour te plomber les performances, surtout quand on en fait une utilisation répétée... dans ce cas il vaut mieux passer par de la compilation de lambda expressions, ou pour des problèmes plus épineux encore, carrément sortir la LCG de son placard (émission de code MSIL dynamiquement).

Utiliser un profileur de code pour repérer les sections qui sont chronophages et qui pourraient éventuellement mériter une amélioration...

pour ce qui est de l'instanciation... allouer de la mémoire sur le tas, n'est pas un acte gratuit... que tu sois en natif ou en managé... le problème reste entier.
il ne faut pas confondre avoir des variables qui de toutes façon ne seront que des zones sur la pile d'exécution (variables locales...) là effectivement pas de temps, mais le fait de faire un instanciation par "new" n'est pas un acte gratuit en terme de temps bien loin de là, surtout sur une plateforme managée où tu ne gère pas toi même la libération... car le système doit utiliser des mécanismes qui lui permettrons de le faire pour toi...
en plus, à l'inverse de C++, la plateforme dotnet assure que tout type instancié avant le démarrage du constructeur, démarre avec des zones mémoire à l'état par défaut, cad valeur par défaut de chaque membre... 0 pour les primitives numériques par exemple... ceci n'est pas gratuit en terme de code natif exécuté...

[davcha]

En fait,

Code :

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

1
2
3
4
Dim asd as Boolean
Dim fgh as String
Dim dsa as Boolean
Dim hgf as String

ou

Code :

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

1
2
3
4
Dim asd as Boolean
Dim dsa as Boolean
Dim fgh as String
Dim hgf as String

Il y a de bonnes chances que ça soit strictement identique en termes de performances.

On aurait pu rencontrer un souci avec l'alignement des données dans la pile, qui aurait provoqué des ralentissements au niveau de la lecture/écriture.

Mais, d'une part, le code managé permet d'éviter ces problèmes d'alignements. La compilation JIT réglant ce problème, je pense.

Et d'autre part, String est un type référence immutable. Donc, au niveau de la pile, ça doit être rien de moins qu'une référence, donc à priori sans problème d'alignement, puisque de la même taille que la largeur de la pile.

[cinemania]

davcha tu as répondu a la question, les string sont bien des classes donc manipulées par référence, qu'elles soient immutables ou non, il y a donc une référence dans la pile, qui est donc alignée sur le type d'alignement de base, donc pas d'opération de padding.