Reprise du message précédent :
Il n'y à souvent pas grande différence en performance sur l'exécution d'une application en Delphi, C++Builder ou VC++.
 
par contre ces 3 derniers outils disposant d'un vrai compilateur natif, ils peuvent produire des application généralement beaucoup plus rapide que les L4G interprétés comme Powerbuilder, windev, etc..
 
Pour ce qui est du système de "compilation à la volée" de .NET, c'est un très bon système, très performant. en particulier les résultats sont très bons si vous faites un petit benchs avec quelques lignes de codes, par ce que dans ce cas .NET a assez de ram pour fonctionner rapidement.
 
le résultat c'est q'une appli VB.NEt (compilation à la volée) peu etre plus rapide qu'une appli VB6 (sytème pcode avec runtime, pas de compilation native).
 
Encore un avantage pour .NET, et qui doit jouer en faveur de l'utilisation de .net versus VB6.
 
par contre si votre application .NET est lourde, et que vous avez pas assez de RAM, le compilateur  à la volé à pas assez de ressources pour bosser normalement, et là ca rame là ou une appli compilée en natif avec Delphi, VC++ ou C++Builder continu à tourner normalement.
 
Donc pour moi il faut soit utiliser un compilateur natif (delphi, VC++, C++Builder) soit .NET en fonction du besoin, et laisser tomber VB6 (et les L4G interprétés en général) ASAP.

en combien d'itérations ???

Bon, j'étais entrain d'écrire quand ... coupure EDF, donc je recommence .
 
Oui, donc, j'ai vérifié ce soir, il y a DEUX modes de compil sous VB6 (et VB5 aussi je crois)
- un mode PCode identique à VB4
- un mode code natif avec quelques options (certes pas autant qu'un compilo C...)
 
Par défaut, c'est le vrai compilo qui est activé. J'ai jamais utilisé le PCode depuis VB4. Donc VB, ça compile.

Vazkor refuse de le croire, c'est pas faute de lui avoir montré et répété

Bon, voila

C'est pas parce que tu as une option qui s'appelle "compile" que ca compile en natif. L'image bien connue cis dessus est une pure escroquerie marketing.
 
la ruse "marketing" existe depuis dbase IV qui à aussi un menu compile.
 
Ca te fait un pacquet cadeau avec dans le meme exe ton pcode plus le runtime.
 
C'est un fait bien connu, vous etes naif.
 
Sinon une appli VB.NET s'exécuterais pas 10 fois plus rapidement  (vraiment compilée à la volé) qu'une appli VB6 "soit disant" compilé.
 
C'est de la pure naiveté.
 
Pour vous en convaicre faite un bench VB 6 versus VC++ versus VB.NET.
 
Vous n'avez meme pas besoin de faire  le bench, il suffisait d'aller à la démo chez Microfot, ou on vous montrait CHEZ MICROSOFT un code VB.NET aussi rapide qu'un code Delphi 10 fois plus rapide qu'un code VB6.
 
C'est de notoriété publique...
 
Troll "VB6 ca compile" deja fait 100 fois...
 
Ca doit etre la méthode coué je supose...
 
 

Ouais c'est ça, les options elles servent à rien et M$ met des boucles d'attentes pour faire croire que la compile est plus complexe qu'une simple concaténation de source comme en PCode   . (j'oubliais aussi les accès disque bidons pour faire bonne mesure )
 
J'ai pas dit que c'était aussi rapide que C++, d'ailleurs MS s'en garde bien. Mais ça "compile", c'est pas du PCode.

J'ajoute simplement qu'en fait, je m'en tappe un peu des perf de VB puisque quand on fait des interfaces, on a pas trop de problème de perfs...
 
EDIT : Si un jour j'ai fait une appli qui bouffe plus de 2% CPU (je caricature un peu, vous aurez compris), et bien je m'appelle Régis...

j'ai déjà fait des benchs VB6 pcode Vs VB6 compilation native et la compilation native s'avère environ 50% plus rapide que le P-Code pour un calcul de factorielle. enfin bon, tu veux pas te rendre à l'évidence, c'est ton choix, on va pas encore polémiquer 107 ans là dessu

50% d'amélioration seulement pour du compilé en natif c'est pas normal, c'est totalement insuffisant.
 
Le facteur devrait etre beaucoup plus élevé, 10 à 40 fois parfois.
 
C'est une solution partielle, et oublie pas la DLL runtime à distribuer avec , oui je dis bien DLL RUNTIME, comme je dis depuis le départ, meme avec la sois disant option de compilation, qui ne te fait que un espèce de compilation partielle à l'aide du compipo de VC++ d'ailleurs.

Une application VB ne peut pas etre compilé en natif, en vérité VB se sert d'une VM (machine virtuelle comme dbase c'est pareil), cf ce document technique, ce qui fait la différence en éxécution par rapport aux vrais compilateurs natifs (C++, Delphi) et à la compilation à la volée (la compilation à la volé et une meilleure technologie que l'anciene VM pour VB). CF :
http://www.programmersheaven.com/a [...] n/vbvm.htm

J'ai regardé ton lien rapidement, mais tu me montres un article qui parle du PCode et qui n'est pas l'option par défaut dans VB5 et VB6 mais qui est la seule dans VB4 et -.
 

ce sujet a déjà été débattu il y a quelques mois:
 
http://forum.hardware.fr/forum2.ph [...] h=&subcat=
 
et ça devient lourd de voir revenir les mêmes personnes avec les mêmes arguments.  je propose qu'on ferme ce topic et basta

Que tu coche ton option ou pas qui change la façon interne de stocker ton programme, cela ne change rien au fait que tu as besoin de la VM pour VB, comme pour les langages dbase ou java.
 
C'est une VM quoi qu'il arrive...
 
Dans les 2 cas tu doit distribuer la DLL, le RUNTIME.
 
 

C'est peut-être aussi qu'il y a pas de linker et que ça passe par une API (DLL) pour de nombreuses fonctions basiques (qui sont en général linké au code en C par exemple). Enfin, je suis pas spécialiste de la conception de l'outil, juste de son utilisation.  
 
Cela dit, tu as raison, c'est hors sujet et j'ai les réponses à mes question.  
 
Merci et ... bonne nuit

Pour moi runtime et VM sont deux choses différentes et les comparer est risible.  Sinon explique moi l'existence de MSVCRT40.DLL (entre autres).  Tout compilateur (quelque soit l'OS cible, MSDOS compris) intègre un runtime dans ou hors de l'exécutable.
 
Là dessus, bonne nuit.

Un petit bench :
 

Delphi et VC++ utilisent un compilateur natif. Si tu n'utilises pas les librairies MFC (VC++) ni la librairie VCL (Delphi) tu n'à besoin d'aucun runtime, d'aucune DLL.
 
Par exemple tu peux faire une appli de 10 Ko avec Delphi ou VC++, c'est impossible avec VB qui à besoin de son environnement runtime VM quoi qu'il arrive, quelque soit l'option de distribution selectionnées (compacte ou pas).
 
Pour VB tu as toujours besoin de la DLL runtime car c'est une VM, et pas vrai un compilateur natif.
 
le fait que MS propose 2 options différentes de distibution, optimisée pour la taille ou l'exécution c'est un autre probleme, et il peuvent appeler cela comme ca leur chante...
 
Note que par exemple Delphi est très performant pour le  traitement des strings, il est meme plus rapide que VC++ dans ce cas.

 
 
VB7

je pense aussi que vb meme compilé ne produit pas un "vrai" code natif suffit d'aller lire les tutos des sites de "cracker" pour voir que l'on ne trace pas un prog vb (compilé ou pas) comme un prog "natif" c'est donc je pense un signe  

Merde C un poste à moi    
 
Et d'accord pour la fermeture de topic... tjs la même chose sauf qu'on rajoute une plateforme de Dev (bon là on est vendredi mais bon   )
Guerre de langage sucks
 
(Delphi  C bien )
 
 
 

Beh en même temps il a raison là  

ouais, on lit toujours la même chose c'est gavant.

Oué et C tjs les même en +  

ca dépends qui participe, et quels langages se fightent.
j'ai déja appris pas mal de trucs en trollant contre plus fort que moi.
 
mais bon, c'est pas sur vb qu'on apprends des masses  

Bon je vais pas épiloguer 107 ans, mais à propos du bench : je sais pas comment il a été fait, mais on ne peut pas comparer les chaines de caractères VB à des Char* ou Char[n] en C. Pire encore, la gestion de tableaux en VB utilise un structure assez complexe qui est cachée à l'utilisateur (même dans le débugger). En fait, ça date déjà des débuts du Basic ces structure. Pour peu qu'on faisse un tableau de chaines de caractères, on passe minimum par trois zones mémoires pour arriver aux données. Pire encore si on utilise des variant ou des données non déclarées. Donc un algo basé sur des chaines de caractères et de tableaux sera forcément nettement moins performant qu'un truc en C++. Encore une fois, VB n'est pas un langage performant, c'est évident, je l'ai déjà dit. Si je dois faire un algo performant, je le fait en C et je lui colle un couche d'interface quelconque pour être accédé par d'autre langages.
 
Même si ce bench me semble probant (vu l'écart), il faudrait mieux voir comment c'est écrit.
 
Allez, à titre d'info : les chaines de caractères Basic :  
La variable est une adresse d'une zone dans laquelle, il y a un entier indiquant la taille de la chaine et une zone contant l'adresse du début de chaine. Si on change la valeur de la chaine, dans beaucoup de cas, VB désalloue la zone mémoire et en recrée une autre ailleurs dans laquelle il met les données et change l'adresse du bloc intermédiaire ainsi que la taille de la chaine. C'est un peu lourd en fait.  
 
Corollaire, il est donc plus rapide de récupérer la taille d'une chaine que la chaine elle-même (même son premier caractère).
 
Pour les tableaux c'est le même genre en un peu plus complexe. C'est pour ça qu'on ne peut pas redimensionner les tableaux sans perdre les données sauf si le redimensionnement ne porte que sur la dernière dimension.
 
Faut aussi bien voir qu'en VB, il n'y a pas de "librairies" commen en C, les références ne sont que des indications pour les links dynamiques à l'exéctution et aussi des facilités de programmation. Quand on programme en C et qu'on fait un PRINT, on utilise une librairie (stdio.h si j'ai bonne mémoire) qui sera linkée statiquement après la compilation dans l'exe. En VB l'équivalent de stdio n'est pas linkée statiquement, il faut donc les DLL VB pour écécuter ces fonctions. C'est pas forcément très intelligent, mais c'est comme ça.  
 
Donc si c'est ça un runtime, ben oui VB a un runtime. Mais c'est pas du PCode, et il n'y a pas d'interpreteur.

Juste une remarque...

Est-il normal de pouvoir compiler ceci en 'Natif' ?
Ça impliquerait que tout accès de variable passe par une recherche dans une table de noms.
C'est pas vraiment l'idée que je me fais d'une compilation en code machine...
 
Pour ce qui est des performances, merci de ne pas oublier qu'en 'Natif' il y a des options pour supprimer les tests de sécurité.

Derrière le type String de VB, c'est de l'Unicode.  Donc si on veut bencher VB par rapport à C/C++ par exemple, il faut éviter le type char  Le type String est par ailleurs réputé très lent en VB.
 
Pour ce qui est du bench, faut voir comment il a été écrit.  Si c'est par quelqu'un qui débute en VB, le bench n'est pas fiable.  J'ai trop souvent vu des gens débarquer d'un autre langage qui pensaient faire pareil en VB, et qui se sont pris des bugs à la pelle.  VB est justement tellement à part qu'il faut "penser" en VB, sinon c'est casse-gueule.
 
Pour ce qui est des remarques de Musaran, c'est même bien pire que cela puisque typiquement, l'erreur "type mismatch" sur les types simples ne se produira qu'à l'exécution, et quasiment jamais à la compilation.  Sur les objets, c'est moins sûr mais ça arrive tout de même (et même trop souvent).
 
Evidemment, une recommandation élémentaire est de toujours avoir "Option Explicit" en haut de chaque module si on veut faire de vieux os

Le mode natif est un mode natif pour VB, rien à voir avec un autre langage.  Pas de compilation en code machine donc.  Il faut savoir qu'environ 98% du temps d'exécution se passe dans les runtimes VB et les librairies systèmes.  2% seulement dans l'application VB.