Comment améliorer la vitesse de son programme?

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

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.

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:

---

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

---

À la place de

Code:

---

1 2 3 4

Dim asd as Boolean Dim fgh as String Dim dsa as Boolean Dim hgf as String

---

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:

---

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:

---

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

---

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

:D

Citation:

---

Envoyé par cinemania

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 ?

Citation:

---

Envoyé par cinemania

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

Citation:

---

Envoyé par cinemania

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

Citation:

---

Envoyé par 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.

---

oui :aie: 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

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:

---

1 2 3

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

---

est strictement identique une fois compilé en CIL à

Code:

---

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:

---

1 2	asd = dsa = true;

---

est équivalent une fois compilé en MSIL à

Code:

---

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é...

En fait,

Code:

---

1 2 3 4

Dim asd as Boolean Dim fgh as String Dim dsa as Boolean Dim hgf as String

---

ou

Code:

---

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.

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.

Euh les améliorations peuvent être à tous les niveaux ... Mais inutile de parler d'amélioration sans connaître la cause, donc la première phase c'est le diagnostic il faut voir où sont les goulots d'étranglement.

Cause classique :

Au niveau base de donnée : L'absence d'utilisation d'index, un schéma pourrit, utilisation de requête très couteuse (avec curseur ou table temporaire par exemple ...).

Design d'application (création des objets, mode de chargement, l'utilisation des transactions ...)

Application Web : Viewstate, utilisation du cache, utilisation d'ajax ...

...

Citation:

---

Envoyé par cinemania

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 le 1er cas il évalue b certes et il regarde s'il vaut 1, il peut pas juste regarder b et prendre un décision !
dans le 2ème cas il évalue b, puis vérifie s'il vaut la constante 1
je ne suis pas sur qu'au niveau du processeur il y a une différences d'instruction ...

Citation:

---

Envoyé par cinemania

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.

---

le compilateur de vs transforme le code est dans les 2 cas il écrit la meme chose (vérifié avec reflector)
m'enfin que ca soit modifié avant ou après pour au final arriver à la meme chose, rien ne sert de dire qu'il ne faut pas écrire if b = true pour gagner des perfs alors que ce n'est pas le cas ...

Citation:

---

Envoyé par cinemania

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é...

---

mouais ...

je viens de 100k new sur une classe avec des champs initialisés en plus ca a pris moins de 10ms
de toute facon si tu as besoin de x variables (même objet) tu vas pas essayer de coder pour travailler avec moitié moins de variables, sinon le programme risque de pas faire ce qu'il faut :aie:

Citation:

---

Envoyé par cinemania

les string sont bien des classes donc manipulées par référence

---

les string sont des types par référence mais géré par la pile comme les integer et autres

Citation:

---

Envoyé par Pol63

les string sont des types par référence mais géré par la pile comme les integer et autres

---

Je ne sais pas ce que tu veux dire précisément, mais les strings sont des types managés, dont tu ne peux pas obtenir l'adresse. Ils sont traités exactement comme une classe quelconque.
Rien à voir avec les variables locales de type primitif, comme integer, qui sont alloués sur la pile.
Les strings sont alloués sur le tas.

oui je confonds 2 trucs différents

Salut,

Concrètement entre la pile et le tas, quelle différence cela produit à par d'ètre allouée en mémoire de manière différente ?

Citation:

---

Envoyé par davcha

Je ne sais pas ce que tu veux dire précisément, mais les strings sont des types managés, dont tu ne peux pas obtenir l'adresse. Ils sont traités exactement comme une classe quelconque.
Rien à voir avec les variables locales de type primitif, comme integer, qui sont alloués sur la pile.

---

Rien à voir avec un quelconque caractère "primitif" du type (je pense que tu veux dire "intrinsèque" :D ) : les types "value" sont alloués sur la pile, les types "reference" sur le tas, avec juste une réference vers l'instance qui est allouée sur la pile.

un détail aussi peut "ralentir" une application, si elle est multi-threadée.
C'est la création/destruction répétée de threads.

si les tâches à exécuter sont rapides, très rapides, quelles ne sont pas alimentées en permanence, donc typiquement ponctuelles sur une données particulière, qu'elle n'ont pas de raison de s'arrêter temporairement pour attendre on ne sais quoi, il vaut mieux ne pas avoir recours aux threads, mais à la ThreadPool qui est vraiment faite pour ca.

pour les traitement plus lourds, ou traitements de fonds quasi-permanents que l'on peut éventuellement alimenter par des structures synchrones, là on préfèrera des threads.

la raison est que la création/destruction d'un thread est une opération extrêmement couteuse en ressources système (et en temps car il faut les traiter ces ressources)
la ThreadPool engendre N threads (N dépend des réglages de celles-ci) à son démarrage, qui attendent sagement qu'on leur confie du travail à effectuer, il n'y a donc pas de cout inhérent à leur création, puisqu'ils sont créés et détruits avec l'application.

mais comme on l'a déjà dit, il serait bon de profiler et de diagnostiquer ton application avant d'aller plus loin dans les conjectures où les conseils, car cela peut simplement venir d'un algorithme mal écrit, et là tu pourra sortir toutes les optimisations possibles au niveau de l'écriture... cela ne changera rien.