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