Performance de VB2008 ?
Résolu
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
-
14 août 2008 à 22:56
Kevin.Ory Messages postés 840 Date d'inscription mercredi 22 octobre 2003 Statut Membre Dernière intervention 7 janvier 2009 - 15 août 2008 à 23:02
Kevin.Ory Messages postés 840 Date d'inscription mercredi 22 octobre 2003 Statut Membre Dernière intervention 7 janvier 2009 - 15 août 2008 à 23:02
3 réponses
gillardg
Messages postés
3275
Date d'inscription
jeudi 3 avril 2008
Statut
Membre
Dernière intervention
14 septembre 2014
2
14 août 2008 à 23:34
14 août 2008 à 23:34
bof pas sur mais est ce vraiment interessant de comparer d'un language à l'autre
je comprends le désir de savoir si vb2008 est plus rapide que son ancetre
mais d'un language tellement different tel le C++ ???
il paraitrait que les programmes en .net sont de toute façon moins rapide que les languages compilés en code natif !
cela réponds déjà un peu à ta question
Bonjour chez vous !
je comprends le désir de savoir si vb2008 est plus rapide que son ancetre
mais d'un language tellement different tel le C++ ???
il paraitrait que les programmes en .net sont de toute façon moins rapide que les languages compilés en code natif !
cela réponds déjà un peu à ta question
Bonjour chez vous !
PCPT
Messages postés
13272
Date d'inscription
lundi 13 décembre 2004
Statut
Membre
Dernière intervention
3 février 2018
47
15 août 2008 à 05:57
15 août 2008 à 05:57
salut us_30,
cette source (ou les comms) tombe peut-être à point :)
http://www.cppfrance.com/codes/VB-DELPHI-CPLUSPLUS-QUEL-EST-MEILLEUR_10375.aspx
faut évaluer les tests dans un ensemble...
perso 30Mo de ram pour un label posé sur une form (vb2005 en tout cas), çà pèse plus dans la balance qu'une opération éventuellement X fois plus rapide ;)
par contre si tu veux faire différents tests, pourquoi pas....
++
<hr size="2" width="100%" />Prenez un instant pour répondre à [infomsg_SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp
cette source (ou les comms) tombe peut-être à point :)
http://www.cppfrance.com/codes/VB-DELPHI-CPLUSPLUS-QUEL-EST-MEILLEUR_10375.aspx
faut évaluer les tests dans un ensemble...
perso 30Mo de ram pour un label posé sur une form (vb2005 en tout cas), çà pèse plus dans la balance qu'une opération éventuellement X fois plus rapide ;)
par contre si tu veux faire différents tests, pourquoi pas....
++
<hr size="2" width="100%" />Prenez un instant pour répondre à [infomsg_SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
15 août 2008 à 23:02
15 août 2008 à 23:02
Salut US,
Ce test m'intéresse particulièrement, car j'ai que trop entendu des "VB.NET c'est lent et très lourd, ca ne vaut de loins pas VB6"
Ce qui est sûr, c'est que le langage interpreté prend bcp plus de mémoire (plein de classes du framework à charger) et demande une compilation au lancement du programme (ce temps peut être énormément réduit grâce à ngen.exe. Un programme d'installation devrait l'éxécuter pour tout programme .NET installé)
Un programme en interpreté .NET n'est donc absolument pas destiné pour un programme résident en mémoire, comme un service ou un driver.
Une fois l'application éxécuté par contre, il est clair que du code .NET est également très rapide. Les classes du framework accèdent aux API Windows comme tout code VB6, et tout ce code est "made by Microsoft", on espère donc que leurs programmeurs savent ce qu'il font et utilise toutes les subtilités possibles pour améliorer les performances au maximum. Après, tout dépend de quoi on parle. Une classe bas niveau, par exemple un Socket, n'est la que pour permettre l'accès à une API à partir d'un code managé, elle n'ajoute aucun traitement (ou très peu) avant d'accéder à l'API. Par contre, si on prend un WebClient, qui lui même utilise un Socket, il est clair que les fonctionnalités ajoutés réduiront les performances.
Maintenant, au sujet de C++. Je ne connais pas le C++, mais encore une fois, il faut savoir de quoi on parle. Si on programme en C++.NET, et qu'on accède à une classe de framework tout comme on le ferai avec VB.NET, je doute que les performances soit très différentes. Par contre, il est évident que si on code en C++ natif, le gain de performance est non négligeable si le code est bien optimisé (une grande partie du framework est codé en C++, sauf erreur). L'avantage avec VC++.NET est qu'on peut mélanger du C++ managé et de C++ natif dans le même assembly, rien de tel pour faire un assembly managé tout en améliorant les performances des partie sensibles.
Le framework n'est rien d'autre que des classes permettant d'accéder au API de Windows, il ne faut pas oublier ce point. Donc qu'on fasse un appel à une fonction du framework ou qu'on appel une fonction accédant à une API qui ne provient pas du framework, je pense que cela vient plus ou moins au même.
En passant, j'ai vu des tests entre JAVA et .NET, et .NET est clairement devant JAVA au niveau vitesse d'exécution.
Tout ceci est mon avis, je n'ai aucune preuve à l'appuis
Ce test m'intéresse particulièrement, car j'ai que trop entendu des "VB.NET c'est lent et très lourd, ca ne vaut de loins pas VB6"
Ce qui est sûr, c'est que le langage interpreté prend bcp plus de mémoire (plein de classes du framework à charger) et demande une compilation au lancement du programme (ce temps peut être énormément réduit grâce à ngen.exe. Un programme d'installation devrait l'éxécuter pour tout programme .NET installé)
Un programme en interpreté .NET n'est donc absolument pas destiné pour un programme résident en mémoire, comme un service ou un driver.
Une fois l'application éxécuté par contre, il est clair que du code .NET est également très rapide. Les classes du framework accèdent aux API Windows comme tout code VB6, et tout ce code est "made by Microsoft", on espère donc que leurs programmeurs savent ce qu'il font et utilise toutes les subtilités possibles pour améliorer les performances au maximum. Après, tout dépend de quoi on parle. Une classe bas niveau, par exemple un Socket, n'est la que pour permettre l'accès à une API à partir d'un code managé, elle n'ajoute aucun traitement (ou très peu) avant d'accéder à l'API. Par contre, si on prend un WebClient, qui lui même utilise un Socket, il est clair que les fonctionnalités ajoutés réduiront les performances.
Maintenant, au sujet de C++. Je ne connais pas le C++, mais encore une fois, il faut savoir de quoi on parle. Si on programme en C++.NET, et qu'on accède à une classe de framework tout comme on le ferai avec VB.NET, je doute que les performances soit très différentes. Par contre, il est évident que si on code en C++ natif, le gain de performance est non négligeable si le code est bien optimisé (une grande partie du framework est codé en C++, sauf erreur). L'avantage avec VC++.NET est qu'on peut mélanger du C++ managé et de C++ natif dans le même assembly, rien de tel pour faire un assembly managé tout en améliorant les performances des partie sensibles.
Le framework n'est rien d'autre que des classes permettant d'accéder au API de Windows, il ne faut pas oublier ce point. Donc qu'on fasse un appel à une fonction du framework ou qu'on appel une fonction accédant à une API qui ne provient pas du framework, je pense que cela vient plus ou moins au même.
En passant, j'ai vu des tests entre JAVA et .NET, et .NET est clairement devant JAVA au niveau vitesse d'exécution.
Tout ceci est mon avis, je n'ai aucune preuve à l'appuis
