Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Thomas Lebrun

Tout sur WPF, LINQ, C# et .NET en général !

Actualités

[WPF] Comparatif des performances entre WPF et WindowsForms

J’entend souvent les gens se plaindre des problèmes de performances de WPF: ce fût même l’occasion d’un “débat” entre développeurs, il n’y a pas si longtemps Wink,qui craignaient d’être obligé d’avoir des machines de développement surpuissantes, pour pouvoir utiliser Visual Studio 10 (qui, je le rapelle, est développé en WPF).

A titre personnel, je n’ai jamasi eu à me plaindre des performances de WPF mais, pour tenter de convaincre les gens, je me suis laissé tenté à faire des petits tests de comparaison de performance, entre WPF et WindowsForms.

Les tests que j’ai effectué (qui ne sont pas exhaustifs et parfaits) sont les suivants:

  • Remplissage de 10 000 objets dans une ComboBox
  • Remplissage de 10 000 objets dans une ListView
  • Remplissage de 10 000 objets dans un Treeview
  • Tri des 10 000 objets qui sont dans la ListView

Pour certains scénarios, il y a plusieurs cas possibles:

  • Utilisation de la virtualisation
  • Tri personnalisé
  • Etc.

Pour que les résultats ne soient pas faussés parce qu’ils sont joués sur ma machine de développement, j’ai lancé le tests sur 2 autres machines, qui sont sans doute plus proche des machines “classiques” que celle dont je dispose:

  • Machine 1:
    • OS: Windows XP SP3 32 Bit
    • Processeur: 1Ghz
    • RAM: 512 Mo
  • Machine 2 (machine de développement):
    • OS: Windows Vista SP1 32 Bit
    • Processeur: Dual Core 2 Duo T7400 @ 2.16 GHz
    • RAM: 4Go
  • Machine 3
    • OS: Windows XP SP3 32 Bit
    • Processeur: Pentium 4 @ 2.4 GHz
    • RAM: 1Go

Comme vous pouvez le constater, les machines sont plutôt diverses ce qui permet d’espérer des résultats intéressants Smile

Disclamer: Avant de livrer les résultats, je me permet de rajouter ceci: Le code que j’ai mis en place pour ces tests ne comporte aucunes optimisations particulières. Il doit-être tout à fait possible de l’optimiser mais dans ce cas, il serait nécessaire d’optimiser les 2 versions (WPF et WindowsForms), pour que le test soit équitable Smile

Maintenant que cet avertissement est mis en place, passons aux résultats: tous les temps sont exprimés en secondes.

Machine 1:

image

Machine 2:

image

Machine 3:

image

Que peut-on conclure de ces réultats ?

Les performances des applications WPF sont supérieures à celles des applications WinForms, hormis pour le contrôle ListView (avec le Virtual Mode d'activé) où les performances des applications WinForms sont d’environ 50% supérieures.

En ce qui concerne le tri, le constat est le même à la différence prêt que l’optimation, pour la version WindowsForms (et mode virtuel activé), permet des performances qui sont légèrement supérieures (pas assez d'ailleurs pour que cela ait un véritable impact).

 

Conclusions

D’une manière générale, les applications WPF sont plus performantes que les applications WindowsForms. Seul le contrôle ListView semble dérogé à ce constat mais la différence est sans doute suffisament infime pour qu’elle soit ignorée.

 

Vous avez la possibilité de vous faire votre propre avis, en téléchargeant la solution (qui contient également le fichier de résultat): http://morpheus.developpez.com/wpf/tools/PerfBench.zip

 

En espérant que cela serve à montrer que WPF, c’est pas si lent que cela peut le paraitre Wink

 

A+

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: mardi 27 janvier 2009 10:38 par Thomas LEBRUN
Classé sous : ,

Commentaires

Graveen a dit :

A noter que la version alpha 4 de SharpDevelop est developpé en WPF, et force est de constater qu'elle tourne aussi bien que sa version en winforms.

Ceci étant Thomas, quelque soit le code utilisé pour tes tests, l'optimisation est assez bluffante.

# janvier 27, 2009 11:12

sebmafate a dit :

ouch !

Voilà de quoi faire taire quelques rumeurs...

au suivant !

# janvier 27, 2009 11:38

richardc a dit :

Hum, j'ajouterais un bémol important : tout peut dépendre de l'endroit ou est placé ton contrôle ;-)

Retour d'expérience sur la grille XCeed : si elle est placée dans une ligne Height="Auto", cela devient une catastrophe (ie recalcul de la hauteur à chaque fois que l'on ajoute une ligne).

Donc oui WPF peut être plus rapide que les WindowsForms, mais oui aussi il peut devenir catastrophique sans que l'on sache facilement pourquoi.

J'en ai discuté il y a peu et je pense de plus en plus que les patterns utilisés pour WPF sont très discutables. La prédictibilité d'un dev WPF est presque impossible et hasardeux.(quelqu'un a fait un masktextbox bindable au niveau du mask ? Un numericUpDown avec possibilité de saisie ?).

Bref, je pense que WPF, c'est cool, mais dangereux ;-)

# janvier 27, 2009 11:55

Thomas LEBRUN a dit :

Pour ce qui concerne la grille XCeed, elle a subit une mise à jour hier: virtualization, etc.... :)

# janvier 27, 2009 12:05

jcq a dit :

Très intéressant et effectivement les tests parlent d'eux mêmes.

2 autres tests intéressant à réaliser:

- Temps de démarrage à froid et redémarrage

- Mémoire utilisée

# janvier 28, 2009 10:00

Fabrice a dit :

"En espérant que cela serve à montrer que WPF, c’est pas si lent que cela peut le paraitre"

C'est bien là le problème. Et je suis bien d'accord avec Richard. Quand on fait du code parfait, il n'y a pas de problème de performance. Le hic c'est que pour produire ce code WPF parfaitement performant, il faut connaitre WPF sur le bout des doigts et éviter tous les pièges qui font qu'une application devient lente.

C'est tellement difficile de faire du code WPF qui tourne bien que, oui, les applications WPF "semblent" lentes. Et dans les faits elles le sont. Le peu d'applications (d'exemple) WPF que j'ai vu sont lourdes, et consomment près de la totalité du CPU même pour des traitements très simples, voire même juste lorsqu'on déplace la souris au dessus des écrans. (Puisqu'on parle d'Xceed, leurs applis de démo, et celles d'Infragistics consomme tout le CPU... ça la fout mal !)

Ca fait peur, et je pense que très peu de personnes arriveront à produire des applications WPF performantes. Il y a à mon avis un gros travail à faire pour produire des outils et un framework de plus haut niveau pour :

1) simplifier le développement des applications WPF

2) permettre d'éviter les pièges qui dégradent les performances

Je sais qu'il y a des outils comme WPFPerf qui aident à détecter les soucis, mais on ne devrait pas avoir à s'en servir dès qu'on commence à développer avec WPF. De base, on ne devrait pas avoir à se poser tant de questions avant de développer son appli de gestion de base.

Du coup, si quelqu'un est partant pour développer SWPF (Simple WPF), qu'il me fasse signe :-)

# janvier 30, 2009 23:33

Thomas LEBRUN a dit :

"Le hic c'est que pour produire ce code WPF parfaitement performant, il faut connaitre WPF sur le bout des doigts et éviter tous les pièges qui font qu'une application devient lente."

Je ne suis pas entièrement d'accord avec toi Fabrice: le benchmark que j'ai fait utilisé du code "tout simple" à savoir du code que n'importe qui (venant du monde Winforms ou ayant déjà développé en WPF) aurait pu écrire..

Cela prouve bien qu'il n'est pas nécessaire de connaitre WPF sur le bout des doigts pour arriver à produire du code performant.

De plus, en ce qui concerne les applications de démos que tu as vu, il est important de noter que ce sont des démos mises en place pour impressionner les utilisateurs de part leur coté graphique: il y a donc sans doute des éléments qui ont été rajoutés (genre BitmapEffect) qui, certes sont très jolis, mais plombe les perf (on peut donc supposer qu'aucun n'effort n'a été fait pour les optimiser)...

# janvier 30, 2009 23:56

Fabrice a dit :

Je suis d'accord, mais une vraie application ce n'est pas juste des combobox est des listviews. On se retrouve rapidement à combiner des StackPanel, des Grid, des Border, avec un minimum de styles et des tailles Auto ou *. Et là tout de suite c'est autre chose. Il est plus facile de faire ce qu'il ne faut pas.

# janvier 31, 2009 00:07

Thomas LEBRUN a dit :

Oui oui, bien sur: c'est poru cela que j'ai marqué que ce bench n'est pas exhaustif mais au moins, il fournit une base.

Je vais essayer de pousser le bench et d'aller plus loin dans cette direction.

# janvier 31, 2009 00:11

Yannick84 a dit :

Un petit comparatif entre une version WPF et MCF serait interessant lui aussi !

# février 13, 2009 15:56

Yannick84 a dit :

MFC plutot ;)

# février 13, 2009 15:57
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- VMMap en mode instrumentation sur système 64bit : attention à la plateforme cible du build .NET par CoqBlog le il y a 6 heures et 58 minutes

- Etendre le Team Web Access de TFS 2012 – Step 0 par Philippe Didiergeorges Aka Philess le 05-23-2013, 23:48

- Simuler facilement l’envoi de mail par Blog de Jérémy Jeanson le 05-22-2013, 12:52

- ProcDump 6.0 : support du filtrage sur messages d'exceptions .NET, des filtres multiples et du ciblage par nom de service par CoqBlog le 05-20-2013, 14:50

- Votez pour le TOP 10 des influenceurs SharePoint francophones ! par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 12:59

- [Conf’SharePoint] Dernier rappel ! :-) par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:09

- [ #SharePoint 2013 ] les modèles de sites standards… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:03

- 10 erreurs de compréhension concernant SharePoint… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 08:27

- Conf’SharePoint : 10 bonnes raisons pour ne pas la rater par Le petit blog de Pierre / Pierre's little blog le 05-14-2013, 02:24

- [Event] Soirée de lancement Agile .NET France à Lyon par Blog Agile/ALM de Vincent THAVONEKHAM le 05-13-2013, 01:29