Unterschied zwischen Native und P-Code?
Marko Opic
Wer kann mir sagen, wo der Unterschied zwischen Compilieren in P-Code und in
Native Code liegt?
Ich habe eine Anwendung geschrieben, bei der ich überhaupt keinen
Geschwindigkeitsunterschied in der Ausführung erkenne, egal ob in Native
(auch die Switches habe ich getestet) oder in P-Code compiliert. Allerdings
schrumpft die Größe der Datei von 1000 auch 650 kb, wenn ich in P-Code
compiliere.
Kann es sein, dass bei kleinen Anwendungen die Compilierungsart völlig
wurscht ist?
Danke und Grüße,
Marko Opic
ma...@opic.de
Stefan Weyer
Nativer Code ist systemnaher Code und muss nicht zur Laufzeit noch einmal
für den Prozessor umgewandelt werden (ich glaube, ein wenig doch, habe da
noch so etwas im Ohr, bin mir aber nicht ganz sicher). Somit sind diese
Anwendungen normalerweise schneller, als mit P-Code kompiliert (habe mal
gehört, ist ein Relikt von VB5). Wenn du das bei deiner Anwendung nicht
merkst, liegt das wohl daran, das sich das ganze nicht im menschlich
realisierbaren Bereich befindet (wie z.B. Klirrfaktor 0,003 oder 0,005).
Wenn man das ganze genau messen würde, denke ich, wird der Unterschied
deutlicher.
Ich persönlich kompiliere immer im Native Code, die Grösse ist mir da erst
einmal egal. Wobei man ja bei den Eigenschaften fürs Kompilieren auch diese
Optimierungen auswählen kann (Grösse / Schnelligkeit).
Gruss
Stefan Weyer
-------------------------
Dirk Schwiewager
beim Native-Compiler laufen Fließkommaoperationen deutlich schneller.
Also wenn du mathematische Datenmengen bearbeitest und berechnest
hast du einen Vorteil in der Geschwindigkeit. Ansonsten habe ich mit
dem P-Code gute und platzsparende Erfahrungen gemacht, auch was
die Kompilierzeit angeht.
Ich mach das so, daß ich Projekte in der Entwicklungszeit P-Code
kompiliere, bei einer Auslieferung dann aber immer Nativ einstell.
Gruß Dirk
Stefan Weyer
da es mich gerade auch nochmal interssiert hat, hier das Ergebnis meiner
Suche:
Wenn Sie die Professional Edition oder die Enterprise Edition von Visual
Basic besitzen, können Sie Ihren Code entweder in das Standardformat von
Visual Basic (P-Code) oder in das systemeigene Codeformat (engl.: native
code) kompilieren. Bei der Kompilierung in systemeigenen Code gibt es
mehrere Optionen zur Optimierung und zum Testen, die im P-Code-Format nicht
zur Verfügung stehen.
P-Code oder Pseudo-Code ist eine Zwischenstufe zwischen den höheren
Anweisungen in Ihrem Basic-Programm und dem systemeigenen Code oder
System-Code, den der Prozessor Ihres Computers ausführt. Zur Laufzeit
übersetzt Visual Basic jede P-Code-Anweisung in systemeigenen Code. Durch
die direkte Kompilierung in das systemeigene Codeformat überspringen Sie die
Zwischenstufe über den P-Code.
Sie können kompilierten systemeigenen Code mit Standardwerkzeugen testen,
z.B. mit der Testumgebung, die von Visual C++ bereitgestellt wird. Sie
können auch die von anderen Sprachen (z.B. Visual C++) bereitgestellten
Optionen zur Optimierung und zum Testen des systemeigenen Codes nutzen.
Beispielsweise können Sie Code hinsichtlich Geschwindigkeit oder Größe
optimieren.
Anmerkung Alle mit Visual Basic erstellten Projekte verwenden die Dienste
der Laufzeit-DLL (MSVBVM60.DLL). Diese DLL stellt u.a. folgende Dienste zur
Verfügung: Start- und Beendigungs-Code für Ihre Anwendung, Funktionsmerkmale
für Formulare und integrierte Steuerelemente und Laufzeitfunktionen wie
Format und CLng.
Das Kompilieren eines Projekts mit der Option System-Code bedeutet, daß der
von Ihnen geschriebene Code statt zu P-code vollständig zu den systemeigenen
Anweisungen des Prozessor-Chips kompiliert wird. Dadurch werden Schleifen
und mathematische Berechnungen wesentlich beschleunigt, und auch Aufrufe an
Dienste, die von MSVBVM60.DLL bereitgestellt werden, können etwas
beschleunigt werden. Die DLL wird dadurch aber nicht überflüssig.
Norbert Schulze-Kahleyß
Der Unterschied macht sich für die Leute, die vom Programmieren leben u.U.
im Geldbeutel bemerkbar: P-Code kann man bei ausgelieferten Programmen
abkupfern, es sieht also jeder der es drauf anlegt, was Du da so
programmiert hast.
Mit der Standardversion kann man nur P-Code erzeugen (sehr zu meinem
Leidwesen).
Schönes Wochenende,
Norbert
Armin Zingler
3a1e470d$0$27445$7d5a...@news.compuserve.de...
> Hallo,
>
> Wer kann mir sagen, wo der Unterschied zwischen Compilieren in
P-Code und in
> Native Code liegt?
s. VB6-Doku:
Arbeiten mit VB -> Programmierhandbuch -> Einsatzmöglichkeiten für
VB -> Leistung und Komp. beim Anwendungsentwurf -> Kompilierte im
Vergleich zu interpretierten Anwendungen
oder
s. MSDN:
Books -> Hardcore Visual Basic -> Chapter 1 -> Efficient Code ->
P-Code Versus Native Code
oder
MSDN: Books -> Advanced MS VB 5 -> Chapter 8 -> Introduction -> Stuff
about the Compiler -> A Little About P-Code
> Ich habe eine Anwendung geschrieben, bei der ich überhaupt keinen
> Geschwindigkeitsunterschied in der Ausführung erkenne, egal ob in
Native
> (auch die Switches habe ich getestet) oder in P-Code compiliert.
Allerdings
> schrumpft die Größe der Datei von 1000 auch 650 kb, wenn ich in
P-Code
> compiliere.
>
> Kann es sein, dass bei kleinen Anwendungen die Compilierungsart
völlig
> wurscht ist?
Nein! Die Frage ist nicht, ob die Anwendungen klein sind, sondern
wieviel zur Laufzeit für selbst programmierten Code verwendet wird.
Damit meine ich, daß ein Print "Hallo" mit native Code auch nicht
schneller ist, da fast die gesamte Zeit für die Ausführung des
Print-Befehl verwendet wird. Da der Print-Befehl lediglich ein Aufruf
einer Prozedur in der VB-Runtime ist, nützt auch die Compilierung zu
native-Code nichts, da sich die Prozedur in der Runtime dadurch
selbstverständlich nicht ändert. Ein For i= 1 to 1000000000:next i
hingegen läßt das Programm bei native Code wesentlich schneller
Laufen, da die meiste Zeit auch tatsächlich im selbst erstellten Code
verbracht wird:
Benchmarks für obige Schleife (wie immer mit Vorsicht zu genießen):
- p-Code: 31,5s
- n-Code ohne Optimierung: 7,6s
- n-Code auf Geschw. opt.: 4,8s
- n-Code auf Geschw. opt.+alle weiteren Opt.: 4,2s
Der Faktor von 1. zu 4. ist immerhin 7,5
Armin
Harald M. Genauck
> Der Unterschied macht sich für die Leute, die vom Programmieren leben u.U.
> im Geldbeutel bemerkbar: P-Code kann man bei ausgelieferten Programmen
> abkupfern, es sieht also jeder der es drauf anlegt, was Du da so
> programmiert hast.
Das geht? Wäre schön, wenn Du uns den Trick verraten könntest, wie das
geht... (vorausgesetzt, wir meinen die gleichen VB-Versionen, etwa 5 und
6... ;-)
Viele Grüße
Harald M. Genauck
--
ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de
Harald M. Genauck
> Ich mach das so, daß ich Projekte in der Entwicklungszeit P-Code
> kompiliere, bei einer Auslieferung dann aber immer Nativ einstell.
Hoffentlich testest Du die nativ-kompilierte Version dann nochmal genauso
gründlich - es gibt hier und da subtile Unterschiede im
Laufzeit-Verhalten...
Norbert Schulze-Kahleyß
bitte klär mich auf!
Bisher war ich der angelesenen Überzeugung, man könne VB6 P-Code
dekompilieren und sei damit der mit Utilities gespickten Konkurrenz
ausgeliefert.
Gespannt,
Norbert
Harald M. Genauck
> Theoretisch: Ja. Praktisch: Womit (Utilities)?
> ...
> Mich persoenlich befremdet es immer wieder ein wenig, dass dieser
> Discompilierungsaspekt in jeder P-Code vs. Native Code Debatte
> auftaucht: Dafuer ist er IMHO viel zu theoretisch, aber er zieht sich
> eben durch solche Diskussionen immer wieder weiter in den naechsten
> entsprechenden Thread.
>
> Ueberzogen formuliert: Reine Panikmache (nur meine Meinung).
Dem habe ich eigentlich nicht viel hinzuzufügen - und den letzten Satz
unterstreiche ich besonders.
Native-Code ist tatsächlich nur dann wirklich effizienter und schneller,
wenn sich der Code auf reine VB-Anweisungen beschränkt, keine VB-Objekte
anpackt und auch keine Funktionen der VBA-Bibliothek verwendet (letzteres
bezieht sich insbesondere auf String-Operationen). In einem Punkt bin ich
mir jetzt nicht ganz sicher - aber ich meine mal gehört zu haben, dass sogar
bei API-Aufrufen die Runtime ins Spiel käme, also auch an diesen Stellen
native Code keinen Vorteil brächte.
Wegen der Unwägbarkeiten der Differenzen zwischen IDE/P-Code und Native-Code
würde ich zu einer vorrangigen Kompilierung in P-Code plädieren und
höchstens extrem zeitkritische Operationen in DLLs auslagern. Das Argument,
Native-Code könne mit Debug-Symbolen gespickt werden und lasse sich so
professionell(er) im VS-Debugger verarbeiten, ist spätestens dann null und
nichtig, wenn es darum geht, die Macken des Native-Kompilers ausbügeln zu
wollen... Ein Argument wäre höchstens der Einsatz von Tools wie etwa der
BugTrapper, der auf Debug-Symbole angewiesen ist.