Discussion :

[shadelv]

Bonjour,

Je souhaite avoir quelques infos à propos de ces trois utilisations de Visual :
- Win32 C++
- Windows Forms C++
- Windows Forms C#

1/
Sur une échelle de 1 à 10, 10 étant le mieux, comment notez-vous la performance de ces 3 projets ?
L'idée que je me fais : 9, 4, 3.

2/
J'imagine que la première solution n'est plus très conseillée maintenant que le 64 bit s'est très largement démocratisé...

3/
Le C# me semble le plus facile à coder et le Win32 le plus difficile.

4/
Windows Form C++ et C# ont tous les deux un garbage collector n'est-ce pas ?


Merci d'avance.

[DonQuiche]

Sur les performances, j'aurais plutôt dit 9, 7, 7 mais c'est très variable selon le scénario : les api win32 pour l'UI ont toujours été lentes en général, GDI+ en particulier, avec des solutions de contournement pour les scénarios problématiques. La couche dotnet y change peu de choses. C++ ou C# ça ne fera aucune différence si tu passes par Winforms, tu seras dans les deux cas dans du code managé, peu importe la syntaxe. En revanche, entre du C++ non-managé et du C#, sans spécifiquement parler de Winforms, compte 30% de surpoids à titre purement indicatif.

Cela dit, les performances... Tu as un besoin particulier ? Parce qu'un appli windows typique, c'est 1% de conso CPU, avec des pointes de 100ms. En règle générale, à moins de concevoir une appli boulimique, temps réel, bas niveau ou avec des impératifs critiques en termes de perfs, je ne vois aucun intérêt à opter pour le C++ pour un nouveau projet, le résultat sera le même pour l'utilisateur.

Enfin, en C++ managé, les objets managés (dont Winforms) sont soumis au GC, les objets classiques ne le sont pas.

[shadelv]

Merci pour ta réponse rapide.

J'utilise une appli de gestion mémoire et de fichier qui est écrite en Delphi.
Ce n'est pas critique ou temps réel mais il y a du bas niveau et quelques fonctions nécessitent énormément de ressources.
Ca peut aller de 40% d'un monocoeur et 100 Mo de RAM à 99% d'un multicoeur et 2 Go de RAM.

Je veux essayer d'écrire une version plus simple et light histoire de me refaire les dents sur la conception et la programmation.
Comme je ne connais pas le Delphi, je me suis tourné vers le C++ et le C# dont je suis plus familier.
Java hors de question.

Intéressant sinon ta notation 9, 7, 7.
Je pensais que les Winforms et le GC réduisaient plus que ça les perfs.
Sinon, quelle note tu donnes à Delphi et Java ?

[zeavan]

je me permet une remarque, sachant qu'aujourd'hui , les compileurs et autre garbage collector sont plus qu'optimise, et bien le facteur directeur de performance pour un developpeur debutant/moyen n'ai pas le language choisi, mais bien sa capacite a apprehender le probleme.

Donc pour ce qui est probleme de performance j'inverserai meme la tendance:

donc c++ : 6
win c++ 7
c#: 8

Dans le iso 2011 de c++ le garbage collector va etre ajoute donc apperemment
ce qui confirme un peu mon point de vue.

[DonQuiche]

@shadelv
Je ne peux pas évaluer Java et Delphi, malheureusement, j'ai trop peu d'expérience sur ces plateformes et je ne connais pas les entrailles des interfaces qu'ils utilisent pour l'UI.

Pour l'évaluation que j'ai donnée, c'est vraiment indicatif : dans certains scénarios elle sera moindre, dans d'autres elle sera supérieure. Si ton appli génère 10k ListViewItem par seconde, la différence entre Win32 et dotnet risque d'être plus prononcée. Pour le dessin personnalisé d'un contrôle en revanche, si tu mets correctement en cache les pinceaux et autres objets GDI+, je pense que mon estimation sera correcte.

Maintenant, au vu de ce que tu nous as dit sur ton appli, est-il raisonnable de penser que ce sont avant tout les traitements, et non l'UI, qui vont être gourmands ? Si tu as une distinction nette, le mieux serait peut-être d'avoir une application C# reposant sur une ou plusieurs bibliothèques C++ non-managé. Au pire, s'il y a une seule opération UI particulièrement gourmande, tu peux d'abord faire un prototype en C# pour évaluer le coût et, éventuellement, tu peux toujours récupérer le handle win32 sous-jacent à un contrôle Winforms et le passer à ta biblio C++ pour qu'elle prenne en charge l'opération.

@Zeavan
J'ai tout de même de très forts doutes. A la rigueur si on parle d'un vrai tâcheron sous-doué ne connaissant ni Win32 ni Winforms, peut-être obtiendrait-il de meilleures perfs avec Winforms car il pourra aisément exploiter l'intellisense pour découvrir des méthodes mieux adaptées s'il est incapable d'utiliser Google ou de réfléchir. Mais, pour réaliser une appli C++ plus lente qu'une appli C#, il faut quand même y aller grassement. Par contre je veux volontiers croire qu'un mauvais développeur produira une appli lente mais à peu près fonctionnelle en C# alors qu'il aurait produit une bouse crashant toutes les 30s en C++.

De plus, que les compilateurs et GC soient optimisés ne compensera jamais le fait qu'en C# il y a plus d'opérations à réaliser pour le CPU qu'en C++ et qu'il faut plus de mémoire (header de 10 octets par instance de classe dotnet). A compétences égales, la différence de performances sera toujours là et loin d'être négligeable pour certains scénarios. Ici, clairement, dans ce scénario, le C++ a un rôle à jouer.

Enfin, quand bien même le C++ gagnerait sous peu un GC, je mets ma main au feu qu'il restera optionnel. A défaut, beaucoup de compilateurs proposeront de se cantonner aux specs pré-2011.

[shadelv]

Tu présumes bien.
Ce seront les traitements qui seront couteux, pas l'UI.
J'afficherai des listes avec tout au plus quelques milliers de lignes.
Je trouve qu'afficher plus n'a pas d'intérêt de toute façon.

Je me disais bien qu'il faudrait mélanger le C++ pur à du Winform...