Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le langage C# pour .NET est il aussi performant en rapidité que C++ ?

Le , par jejerome

442PARTAGES

0  0 
Bonjour,

J'aurais aimé avoir des indications sur la performance du langage C# :
ce langage donne-t-il des résultats comparables au langage de programmation C++ en terme de rapidité ?

En particulier : le langage de programmation C# permet-il de réaliser des applications plus plus performantes que feu Visual Basic 6 ?

Merci d'avance pour votre aide

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 16/05/2009 à 17:02
- C# est généralement aussi performant que VB.NET puisque c'est la même chose quasiment : dans les deux cas c'est basé sur le framework .NET et cela utilise la même technologie pour l'exécution.

- Sur une machine récente avec assez de mémoire vive disponible, une application C# ou VB.NET peut être plus performante qu'une application faites avec Feu l'ancien Visual Basic 6, car VB6 n'a pas de compilation native et la technologie d'exécution de DotNET est plus moderne et performante que l'exécution du code pseudo compilé du feu VB6.

- Généralement une applications compilée avec C++ pourra être plus rapide d'exécution qu'une application exécutée avec le framework .NET, cependant cela n'est pas toujours vrai car la technologie d'exécution des applications DotNET s'adapte dynamiquement à la machine cible alors que si tu diffuse un exécutable fait à partir de C++ il n'est nullement optimisé pour une machine cible en particulier. Bref avec les machines moderne dans plus de 90% des cas la performance des applications n'est pas un critère pour un choix technologique de cette importance.
2  0 
Avatar de cedricgirard
Membre averti https://www.developpez.com
Le 01/03/2004 à 13:40
Globalement le C# est logiquement un poil plus lent qu'un langage compilé natif vu qu'il passe par un pseudo code, une librairie enorme.
Maintenant la perf d'un programme est surtout liée à tes algoritmes, et seulement un peu à la performance pure du compilo. En dehors de besoins tres particuliers, tu t'en fous.
Mais tu n'as pas donnés tes besoins? On ne peut pas vraiment te répondre.
1  0 
Avatar de Razispio
Futur Membre du Club https://www.developpez.com
Le 16/05/2009 à 17:22
C# et C++ peuvent sont comparables dans de nombreux domaines (Application bureau, UI etc.) mais il sera surement plus lent que me c++ si du fait du calcul lourd (3d, HPC etc.). Enfin il vaut mieux optimiser ses algorithmes d'abord, et l'augmentation de la productivité peut être plus important que la vitesse d'éxecution.
1  0 
Avatar de zeavan
Membre éclairé https://www.developpez.com
Le 17/05/2009 à 7:25
Dans 99% des cas ce n'est pas le language qui joue sur la performance mais le developpeur lui-meme, je pense pouvoir te rassurer en te disant que je pense que tu ne fais pas parti des 1% en tout cas pas encore.

Donc la question que tu dois te poser n'est pas une question de performance mais plutot de besoin, quel est de ces 2 languages m'est-il plus approprie pour un projet type donne.
1  0 
Avatar de Jidefix
Membre éprouvé https://www.developpez.com
Le 18/05/2009 à 11:03
Citation Envoyé par aityahia Voir le message
salut.

a mon avis avec la puissance des machines actuelle la rapidité n'est pas un atout majeur, par contre un bon langage est celui avec lequel on peut offrir a l'utilisateur plus de fonctionnalités en un laps de temps plus court, c'est le cas de C# avec le Framework .NET.

a+
Je ne suis pas tout à fait d'accord, surtout dans le cadre d'une grosse application, les machines ne compensent pas à l'heure actuelle des programmes lourds et non optimisés.
En revanche effectivement le langage n'est pas le critère qui va compter dans la rapidité d'un programme. Beaucoup moins que la conception et la simplification du code source.
1  0 
Avatar de Neolander
Membre régulier https://www.developpez.com
Le 18/05/2009 à 11:23
Pour la performance, je voudrais relativiser ce qui a été dit plus haut. C'est actuellement à la mode de penser que la performance du langage est moins importante que la rapidité de développement qu'il permet, mais ce n'est pas toujours vrai.
Il faut vraiment effectuer son choix en fonction de ce qu'on veut faire.

Pour des tâches répétitives et relativement simples, les langages compilés sont BEAUCOUP plus adaptés.

A titre d'exemple, pour modéliser un ballon avec un algorithme simple basé sur la loi des gaz parfaits, on a besoin de
-Décomposer le ballon en une série de segments
-Faire une série d'opérations faisant évoluer la simulation à répétition, le plus vite possible parce que sinon d'une part le résultat à l'écran n'est pas fluide et d'autre part il perd en exactitude (ce qui est vraiment problématique dans certains cas).

En python, avec suffisamment de segments pour que la forme obtenue semble ronde, je pouvais obtenir une douzaine d'images par seconde sur une machine un peu datée. En C, on approchait plutôt de la cinquantaine avec le même algorithme

Les langages interprétés sont souvent plus pratiques, mais il ne faut pas leur confier des tâches onéreuses en ressources. Sinon, il faudra un PC de guerre pour faire tourner tes programmes... Je pense qu'il vaut mieux connaître les deux.

Exemples de cas où les langages interprétés sont plus adaptés :
-Applications graphiques qui affichent des fenêtres et des jolis boutons et stockent des réglages dans des fichiers (ex : panneau de configuration windows)
-Logiciels de bureautique
-Logiciels de lecture multimédia, widgets, et autres petites applications de bureau
-Applications destinées à tourner sur un grand nombre de machines différentes, avec des matériels et systèmes d'exploitation variés

Exemples de cas où ils sont à bannir, à part quand on a la chance de trouver une fonction toute faite (programmée en C :p) pour le faire :
-Simulation physique
-Édition multimédia
-Manipulation de fichiers nombreux ou lourds (ex : bases de données)
-Programmes qui doivent tourner très souvent (plusieurs fois par secondes)
1  0 
Avatar de Alp
Expert éminent sénior https://www.developpez.com
Le 19/05/2009 à 1:49
Citation Envoyé par aityahia Voir le message

par contre un bon langage est celui avec lequel on peut offrir a l'utilisateur plus de fonctionnalités en un laps de temps plus court, c'est le cas de C# avec le Framework .NET.
a+
Et de C++ avec des frameworks qui s'imposent presque en standard.
1  0 
Avatar de Alp
Expert éminent sénior https://www.developpez.com
Le 21/05/2009 à 1:31
Citation Envoyé par hegros Voir le message
Dans quelles couches logicielles ces frameworks s'imposent en standard ? De ce que je connais et peux compiler avec code::blocks ou visual studio c'est plus du domaine de l'utilitaire
Mouais.
Je ne considèrerais ni Boost ni Qt comme des "utilitaires". La différence c'est qu'il n'y a pas UNE boîte derrière le C++ pour tout gérer, et surtout le C++ n'a été normalisé qu'en 98 pour la première fois. Avant cela, et encore un peu après, chacun faisait ce qu'il voulait dans son coin.
Au passage, C++0x intègrera pas mal de chose, dont le support *standard* du multithreading, et pas mal d'autres choses intéressantes. Dans un Technical Report de C++0x on pourrait bien avoir le réseau (Boost.Asio) intégré en standard également. Une proposition a été faite.

Bref, si on se renseigne au bon endroit, on peut développer du code C++ pour une quantité impressionnante de plateformes (un code utilisant Qt même pour le GUI passe tel quel sur de plus en plus de portables, par exemple), avec l'efficacité, sans avoir à se trimballer des pointeurs partout (depuis des années, on voit les pointeurs partout comme une mauvaise pratique du C++, on parvient enfin à faire comprendre aux autres que le C++ moderne est un langage qui n'a plus tant de choses que ça de communes avec le C), à gérer la mémoire à la main, etc. Et des bibliothèques comme Boost ou Qt fournissent une quantité énorme d'outils, du GUI au réseau, du Multithreading à la métaprogrammation, de la manipulation avancée de flux à l'intéraction avec des BDD, etc ...

Bref, beaucoup de gens évoluent dans leur langage de prédilection sans ouvrir les yeux sur, par exemple, l'évolution du monde C++. Et ils se retrouvent donc à ressortir des arguments qui datent de 10 ans. Je le sais car je m'amuse à faire la même chose pour Java (pour plaisanter)
1  0 
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 03/06/2009 à 12:17
De toutes façons, la rapidité d'un programme, c'est 20% le matériel, 20% le langage, et 60% l'algo... C'est "empirique", mais c'est souvent très vrai.

On peut de toutes façons distinguer trois types de langages :
- Interprétés,
- Managés / pseudo-code,
- Natifs.

Les langages interprétés (Python, PHP, Ruby, LUA, Javascript, ...) nécessitent un interpréteur pour fonctionner (si, si, j'vous assure ! ), et souvent uniquement un interpréteur, mais offrent alors une portabilité colossale... La plupart des interpréteurs sont en ligne de commande, et peuvent être compilés sur quasiment n'importe quel système existant.
De plus, ils permettent des choses difficilement accessibles aux autres langages, comme la modification de code à la volée et l'auto-modification des programmes.

Inconvénient, ils sont souvent très lents... Dans le cadre d'un séquenceur / système de contrôle, ça n'a aucune importance. Si c'est pour du calcul lourd, c'est plus que rédhibitoire. Certains de ces langages sont "améliorés" en terme de vitesse d'exécution via une "compilation" à la volée lors de la première exécution (PHP notamment est plutôt efficace à ce sujet).
Autre inconvénient, les erreurs de syntaxe ne sont pas forcément détectées au lancement du programme, parfois c'est lorsque l'on arrive sur la ligne fautive uniquement (voire avec des valeurs particulières en plus), ce qui rend le test extensif de tels programmes assez pénible.

Les langages managés / en pseudo-code (.NET, inclus C# bien sûr, et Java) sont nettement plus véloces que les langages interprétés, par contre ils nécessitent un compilateur, un débugger, un IDE / gestionnaire de projets, bref toute une chaîne de développement. Leur portabilité est limitée à celle du framework qui les soutient (JDK/JRE, .NET) : si le framework existe, les programmes pourront être portés. Sinon, ça risque d'être coton, voire infaisable sans l'aide de la société éditrice. Avantage, par contre, si le framework existe, le programme n'a pas besoin d'être recompilé pour être utilisé sur une autre plate-forme matérielle.
Là aussi, une compilation "native" du pseudo-code est en général faite à la première exécution, pour accélérer le traitement... Cela ne résoud pas tout, hélas.

Enfin, les langages natifs, les plus "lourds" à gérer, produisent du code directement exécutable par le processeur, et sont compilés pour un couple processeur / système d'exploitation "figé". Un exécutable C compilé pour PowerPC / Linux ne fonctionnera JAMAIS tel quel sur une machine Windows / x86... Le programme devra être recompilé impérativement. De plus, le code binaire produit n'est pas le même en fonction du compilateur, et encore moins en fonction du langage source. Le débuggage peut s'avérer difficile et fastidieux en fonction des optimisations du compilateur, voire dans certains cas quasi-impossible.
Par contre, c'est le seul moyen d'obtenir des performances maximales (ou presque), en fonction du langage utilisé toutefois, et normalement déployable sur n'importe quelle plate-forme compatible avec simplement un "jeu" de librairies dynamiques (runtimes) pour certaines applications.

Par exemple, en considérant à chaque fois un matériel identique et des algos optimisés au quart de poil, on a souvent le classement suivant pour les langages les plus connus : Assembleur < C < C++ < Pascal/Delphi < ADA
Après, il faut voir aussi la vitesse de développement avec chacun de ces langages : faire un truc qui ne crashe pas en assembleur, ça peut devenir vite une prise de tête colossale... En ADA, par contre, c'est plutôt "si ça compile, ça marche", vu la rigueur colossale du langage au niveau de la phase lexicale/syntaxique...

Cela ne change pas qu'entre un programme en C, avec un bon algo, et son équivalent Java avec un algo tout aussi optimisé, la différence de performances sera réelle, mais pas forcément aussi énorme qu'on pourrait le croire (hors calculs lourds, faut pas pousser non plus). Par contre, la vitesse de développement avec un langage de très haut niveau est bien plus réduite qu'avec un langage "bas niveau".

De même, en restant dans le domaine d'un "lourd" du domaine, C++ : entre un programme C++ "brut", où tout est développé / optimisé "à la main", et un programme C++ écrit en utilisant intensivement les templates, la STL et des API comme QT, le résultat final est là aussi clair et net : la version "à la barbare" est plus rapide (à optimisation d'algo égale, bien entendu), mais la version "soutenue" par des librairies de haut niveau a par contre pris deux fois moins de temps (au moins !!) à être écrite...
Quant à la perte de performances, même si elle est toujours mesurable, c'est parfois bien moins de 1% de différence si l'on n'est pas en train d'écrire une application de calcul lourd et/ou brassant d'énormes quantités de données...

Si c'est pour faire une application à usage unique / interne, une faisabilité, ou encore un outil de test, ou encore quelque chose de souvent modifié, il faut sérieusement se pencher sur la question du temps de développement... Et envisager les langages interprétés.
Si c'est pour quelque chose ne devant pas être touché, devant être rapide, diffusé largement, etc. alors les langages natifs sont à préférer.
Si cela ne doit pas être touché, diffusé largement mais que la rapidité d'exécution n'est pas cruciale, les langages managés sont l'idéal.

Comme dans presque tous les domaines de l'informatique, le choix du langage, c'est surtout une question de besoins et de contraintes de développement...
1  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 04/04/2014 à 9:58
Citation Envoyé par ChipRaptor Voir le message
...
C'est un beau déterrage de thread (presque 4 ans depuis le message précédent !), mais il tombe à pic : Microsoft vient d'annoncer .NET native, qui ambitionne de donner aux applications .NET les performances de C++
1  0