Pourquoi le VB est lent ?

cs_azerty25 Messages postés 1114 Date d'inscription jeudi 19 décembre 2002 Statut Membre Dernière intervention 6 mai 2007 - 15 juin 2004 à 18:37
moimatthieu Messages postés 68 Date d'inscription jeudi 17 juillet 2008 Statut Membre Dernière intervention 6 mars 2010 - 11 déc. 2008 à 11:14
Lu all

Partout sur la terre, on parle du VB comme un langage lent, ce qui est vrai, mais personne n'a jamais dit pourquoi il est comme ça. Apres tout, le code sortit n'est pas du code assembleur ?! Sa vient du fait que c'est un langage interprété ? Et ça signifie quoi interprété par rapport à un langage "normal" comme le C.
Voila, c'est les quelques questions que je me pose ;)
Merci d'avance à ceux qui me répondront

@Z3RtY25 ==

6 réponses

cs_LordBob Messages postés 2865 Date d'inscription samedi 2 novembre 2002 Statut Membre Dernière intervention 11 mai 2009 9
15 juin 2004 à 19:01
si le vb est lent c'est effectivement parce que c'est un langage interprete... en comme tu peux le constater pour tu ne peux executer un programme vb sans les fameux runtime, c'est un lngage interprete parce que en fait il contient des instructions qu'il ne comprend pas, mais en allant chercher dans les runtime il la comprend... bon c'est mal expliké mais c'est un peu l'idee... la difference avec l'assembleur par exemple, c'est que l'assembleur est un langage de ba niveau, et l'assembleur genere des programmes totalement autonome, ce qui le rend plus rapide car il na pas a allé chercher dans les dll des instruction pour pouvoir s'executer correctement...
Bob...

"La chance accorde ses faveur aux esprits avertis..."
0
cs_CanisLupus Messages postés 3757 Date d'inscription mardi 23 septembre 2003 Statut Membre Dernière intervention 13 mars 2006 21
15 juin 2004 à 20:49
Salut,
Entièrement OK avec LordBob et je dirais même plus. Non seulement VB est un langage interprété mais il se veut mulri plateforme et donc portable d'une machine à l'autre. Contrairement à l'assembleur ou plutot aux assembleurs car il en existe autant que de types de processeurs même si les instructions de bases sont partout pareilles.
Si tu veux une solution intermédiaire, le c/c++ est, à mon avis un bon compromis quoique il est + rapide en mode console qu'en mode windows.
Enfin, tout dépend de ce que tu veux faire, il existe tellement de langages spécialisés.... mais, j'y reviens toujours, presque tous basés sur le C (le langage le plus proche de la machine sans être incompréhensible par un humain).

Cordialement

CanisLupus
0
cs_DARKSIDIOUS Messages postés 15814 Date d'inscription jeudi 8 août 2002 Statut Membre Dernière intervention 4 mars 2013 131
16 juin 2004 à 07:14
Il faut faire la part des choses entre rapidité du langage et rapidité de la programmation : programme en Assembleur, et tu verra le temps que tu va mettre pour faire un programme (quasiment irréalisable de faire un prog complet avec l'assembleur) mais le programme sera extrêmement rapide si tu utilise des algorithme optimisé !
Programme en VB, et tu obtiendras un programme très vite fait qui peut être tout de même rapide si tu utilise les bons algorithme et que tu ne te limite pas aux fonctions de base de VB (notamment en utilisant les fonctions de l'API Windows pour le graphisme par exemple), tu peux même obtenir des performances proches du C.
Programme en C/C++, et tu obtiendras, selon moi, le meilleur compromis entre rapidité du code et rapidité de programmation : le C/C++ est un peu plus compliqué que le VB a comprendre et manipuler, mais une fois que tu t'y est lancé, tu peux faire beaucoup de chose rapidement. Niveau performance, avec le même algorithme qu'en VB, tu y gagneras du temps, c'est évident, mais ce ne sera pas non plus de l'ordre de 1000%, il faut pas rêver ! VB est très bien pour concevoir des petites applications qui ne demande pas forcément à être très optimisées, et de toute façon, la perte de performance à cause de l'utilisation de VB sera compensé à court terme par la hausse des performances de nos machines...

Alors pourquoi VB est lent ? Ben franchement, je ne le trouve pas si lent que cà si on utilise les bons algorithme comparé à du C : un bon algorithme en VB est bien plus rapide qu'un mauvais en C ! Personnellement, je préfère tester mes algo en VB car je sais que s'ils sont performant en VB, il le seront aussi en C !
VB est lent à cause de sa bibliothèque standard qui supporter énormément de fonctions de base, contrairement au C par exemple. De plus, certaines fonctions sont très lente, par exemple les fonctions graphiques POINT et PSET !

Maintenant, savoir si tu y gagneras beaucoup à passer au C/C++ : détrompe toi, lors de mon passage à ce langage, je fut plutôt décus de la différence qui est loin d'être énorme pour les petits progs que je fais, mais peut-être que sur un progs bien plus grand, l'écart de performances n'est pas négligeable, à voir...

DarK Sidious

[Responsable API/VB du site www.ProgOtoP.com]
Téléchargez ProgOtoP API Viewer
0
cs_azerty25 Messages postés 1114 Date d'inscription jeudi 19 décembre 2002 Statut Membre Dernière intervention 6 mai 2007
16 juin 2004 à 10:28
Merci pour vos réponses, sa a comblé ma curiosité. J'ai pas dit que VB était super lent, mais tout le monde le sais et le dit, moi même je le constate dans certains de mes progs qui font des boucles qui entrainent des actions graphiques (ou c'est peu etre un peu aussi mon PC). L'idéal serait de le faire en C mais j'y connai rien et j'ai pas spécialement envie d'appendre :(

@Z3RtY25 ==
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
cs_DARKSIDIOUS Messages postés 15814 Date d'inscription jeudi 8 août 2002 Statut Membre Dernière intervention 4 mars 2013 131
16 juin 2004 à 10:38
Tout dépend des algorithmes et des fonctions que tu utilisent : pour le traitement graphique, il faut absolument passer par les fonctions de l'API pour accèlerer le traitement sur des pixels (voir ma source sur la librairie SetPixel : environ 20 fois plus rapide entre GetDIBits et GetPixel, impressionnant ! Et avec cette librairie, l'accès aux bits d'une image est grandement simplifié !)

DarK Sidious

[Responsable API/VB du site www.ProgOtoP.com]
Téléchargez ProgOtoP API Viewer
0
moimatthieu Messages postés 68 Date d'inscription jeudi 17 juillet 2008 Statut Membre Dernière intervention 6 mars 2010
11 déc. 2008 à 11:14
Bonjour à tous

Depuis ce matin je suis en train de prendre la tête sur une partie de mon code qui lit 80000 bits dans un fichier et dois les traiter avec de simples petits while et if mais la raison de ma prise de tête c'est qu'il lui faut environ .... euh .... 3 HEURES pour traiter 1 fichier . Mon programme n'est pourtant pas complexe : j'ai 35 IF et 4 Do while qui font dans 98% des cas seulement de 1 à 5 tours et tout le reste ce ne sont que des +,-,*,/ , un 2^n et deux appels à la fonction Format.
Alors pourquoi c'est aussi long ??? Quelqu'un aurait une explication ??
Je sens que je vais PT un câble

Merci d'avance de vos réponses

Matthieu
0
Rejoignez-nous