Version imprimable
Actuellement, mon code est natif et le passage à un code managé est à l'étude.
Comme l'application en question va devoir traiter un nombre important de données [fichiers, base de donnée, ...], la question des performances est prioritaire.
Plus précisément, est ce que l'utilisation de la CLR va ralentir l'exécution du programme ou les optimisations qu'elle implique apporteront plus de rapidité ?
clairement : ralentir l'execution .
Le code natif n'est pas natif pour rien !!!
Cependant avec un code managé tu gagne en securité , temps de developpement, possibilité d'interfacage,... and many many more... mais pas en perf...
C'est toujours bon de bien mettre les pieds dans le plats :P
Merci pour ta prompt réponse :king:
Je réouvre le sujet suite à quelques recherches sur le sujet.
Il semblerai que malgré la surcharge système de la CLR, il serait possible d'avoir une meilleur utilisation des ressources par une optimisation du code natif généré par le CLR et par une gestion plus point de la mémoire et des instructions spécifiques du processeur utilisé.
Je voulais savoir ce que vous en pensiez.
Par soucis d'objectivité, je ne peux pas trop m'avancer sur le sujet. Je cherche toutes les raisons pour passer au C# mais il faut que mon directeur technique soit rassuré sur les performances finales par rapport à du C++.
Si vous avez des expériences comparatives dans le domaine, je suis preneur car j'ai toujours mes chances de défendre mon petit bout de gras si C# est juste derrière C++. :aie:
Je me suis retrouvé il y'a quelque temps dans cette situation : nouvelle version d'un soft à refaire en C#, avec un gros point d'interrogation sur les performances (d'autant que les choix d'architecture étaient assez ambitieux, archi n-tier (C# du serveur au client riche) avec des frameworks de notification, de mapping O/R, etc fait maison (en C# eux aussi)).
Au final le bilan que je ferai de cette expérience :
- Les perfs sur les algo complexes et sur les parties de code critique sont tout à fait satisfaisantes.
- Côté client, l'IHM à posé quelques problemes de perf (il faut dire qu'on utilisait des dégradés de couleurs, de la transparence etc).
Pour résumer, à part l'IHM qui "rame" lorsqu'on manipule des formulaires trop compliqués (composés de nombreux composant, user controles, le tout créé dynamiquement....) le reste offrait des performances supérieures à nos attentes.
Et donc un très bon choix dans notre cas, car nous nous somme permis de mettre en place une archi et une série de framework très souples et puissants (en privilégiant l'archi / le design sur les perf, quitte à optimiser plus tard si besoin) pour obtenir en fait une application qui répondait parfaitement malgré la complexité des traitements.
Après tout dépend donc tu type d'application que tu développe, pour ma part j'aurai tendance à te mettre en garde si tu prévois de réaliser des IHM complexes (d'autant plus que c'est ce qui est directement sous les yeux de l'utilisateur, rien de pire qu'un IHM qui "clignote de partout" lorsque tu passes d'un tab a un autre...). Pour le reste, je te conseille tout de même de faire des bench mark ou de petit proto, mais je ne serai pas inquiet des performances à attendre - pour ma part j'ai été bluffé (comme je le suis avec les applications actuelle en Java, comparé à ce que j'ai connu il y'a quelques années...).