Schnelligkeit von Befehlen

Computer: Software & Programmierung Visual Basic
#1

Hallo Wissende,
ich habe kein Vb, nur Excel-Vba, aber müßte darin gleich sein *glaub*

Ich kann sowas schreiben:

(X kann nur 2 oder 3 sein)

If x=2 Then
 Range("A1")=Range("A1")+5
Else
 Range("A1")=Range("A1")+7
End if

oder sowas:

Select Case x
 Case 2
 Range("A1")=Range("A1")+5
 Case 3
 Range("A1")=Range("A1")+7
End Select

Dies kann ich 100.000 mal in einer Schleife aufrufen lassen und die Zeiten stoppen, danach weiß ich was schneller ist.

Nur, auf diese Art müßte ich ja um einen Code zu „tunen“ sehr viele Messungen durchführen.

Ich hatte mal vor Jahrzehnten einen Kurs in C, nahezu alles vergessen, aber ich weiß noch genau, wir bekamen da eine Liste wo genau stand wieviel Zeit (relativ zur CPU-Taktfrequenz) ein Befehl braucht um sich auszuführen.

For x = a to b

brauchte eine feste bekannte Zeit, abhängig davon, wie x deklariert war, also 1 Byte, 2 Byte usw, desgleichen für a und b.
Feinheiten, ob jetzt x x heißt oder xxxxxxxxxx wurden weggelassen.

Somit hätte ich die beiden Anfangsbeispiele nicht durchmessen müssen, sondern hätte anhand der Liste schauen können, was denn nun schneller ist.

Sorry für den langen Vorspann, jetzt zu meiner Frage, existiert so eine Liste auch für VB? Für Excle-Vba nehme ich das auch sehr gerne :smile:

Wenn nicht, hat jmd. Links zu Seiten wo Tuningstipps für Vb(A) Code stehen?

Die Basics sind mir schon bekannt, Variablendeklaration, Konstanten einsetzen, kurze Namen, in If-Bedingungen das wahrscheinlichere zuerst usw.

Danke ^ Gruß ^ schönes WE
Reinhard

#2

Hallo,
Wenn es nur ums Tuning von Excel geht, dann kannst Du mit dem Screenupdate = false schon ein wesentlich schnelleres excell erleben.
Wenn Du sowas wie Oben möchtest, solltest Du es aber so schreiben:
If x=2 Then
Range(„A1“).value=Range(„A1“).value + 5
Else
Range(„A1“).valu=Range(„A1“).value + 7
End if

Überigens habe ich auch schon mal sowas gemmacht, dann habe ich excel über 65536 Zellen gejagt mit der for next Schlaufe und neben an die Zeit Markiert im Format double. Die Zeitdifferenz durch anzahl Codezeilen ergiebt dann die ungefähre Geschwindigkeit des Programmes. Hast Du die Zeit von Double, so ist Wert = Wert + 1 einen Tag. also aufgepasst beim Umrechnen, aber Du kannst die Millisekunden sehen.
Grüsse Sebastian

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#3

Hallo Reinhard,

ich habe kein Vb, nur Excel-Vba, aber müßte darin gleich sein
*glaub*

Nö.
VB wird compiliert, da spielt es zur Laufzeit keine Rolle mehr wie lange die Variablennamen einmal waren.
Bis VB4 wurde P-Code verwendet, VB 5 & 6 können P-Code und Maschinencode erstellen.
Seit .NET wird wieder eine Art P-Code verwendet.

Das ergibt alles unterschiedliche Laufzeitverhalten.
Hinzu kommt noch, dass es nochmals unterschiedliche Resultate gibt, je nachdem welche Optionen und Optimierungen eingeschaltet sind.

Mit VBA kenne ich mich weniger aus, aber z.B. unterschiedliche Excel-Versionen verhalten sich auch unterschiedlich.

MfG Peter(TOO)

#4

Hallo Sebastian,

Wenn es nur ums Tuning von Excel geht, dann kannst Du mit dem
Screenupdate = false schon ein wesentlich schnelleres excell
erleben.

Jepp, ich kenne uch application.calculation=xlmanual usw.
Das meinte ich mit Basics, die habe ich drin.

Wenn Du sowas wie Oben möchtest, solltest Du es aber so
schreiben:
If x=2 Then
Range(„A1“).value=Range(„A1“).value + 5
Else
Range(„A1“).valu=Range(„A1“).value + 7
End if

Das ist doch genau meine Frage, ist z.B. Range(„A1“).value schneller als Range(„A1“)?
Wegen Schreibfaulheit läßt man oft .Value weg, bis halt mal der Code kracht weil man nicht .Value braucht sondern .Text, was oft das Gleiche ist, aber nicht Dasselbe.

Überigens habe ich auch schon mal sowas gemmacht, dann habe
ich excel über 65536 Zellen gejagt mit der for next Schlaufe
und neben an die Zeit Markiert im Format double. Die
Zeitdifferenz durch anzahl Codezeilen ergiebt dann die
ungefähre Geschwindigkeit des Programmes. Hast Du die Zeit von
Double, so ist Wert = Wert + 1 einen Tag. also aufgepasst beim
Umrechnen, aber Du kannst die Millisekunden sehen.

Man sagt, eingebaute Excelfunktionen sind 10.000 mal schneller als Vba Code. Jetzt wo es Excel2007 mit 1 Million Zeilen und Spalten bis ähem k.A. vwy o.ä., gibt, wird es für mich immer interessanter, wo stehtst eigentlich genau mit dem 10.000 mal schneller, und wenn ich Vba-Code bastle, welche Befehle sind im Vergleich die schnelleren, soll ich, wenn es die Problemstellung erlaubt, .find nehmen, oder application.worksheeetfunction.match oder application.worksheeetfunction.vlookup usw.

In meinen 3 Büchern zu Vba die ich habe sind dazu nur erbärmlich wenig Infos:frowning:

Im Prinzip suche ich eine Seite, wo sich jmd. wie der bewundernstwerte Mensch von

http://www.xlam.ch/xlimits/index.htm

die Zeit genommen hat, alles mal so auszutesten und die Ergebnisse anderen zur Verfügung zu stellen.

Gruß
Reinhard

Grüsse Sebastian

#5

Hallo Peter,

ich habe kein Vb, nur Excel-Vba, aber müßte darin gleich sein
*glaub*

Nö.
VB wird compiliert, da spielt es zur Laufzeit keine Rolle mehr
wie lange die Variablennamen einmal waren.

Vba wird doch auch kompiliert und nicht zur laufzeit interpretiert?

Bis VB4 wurde P-Code verwendet, VB 5 & 6 können P-Code und
Maschinencode erstellen.
Seit .NET wird wieder eine Art P-Code verwendet.

*hüstel* was isssn P-Code? Maschinencode, Assemblersprache ist mir bekannt, wenn ich sie auch nicht kann.

Das ergibt alles unterschiedliche Laufzeitverhalten.
Hinzu kommt noch, dass es nochmals unterschiedliche Resultate
gibt, je nachdem welche Optionen und Optimierungen
eingeschaltet sind.

Du meinst damit daß man im Kompiler einstellt dass z.B. Code nur innerhalb einer 64 KByte Grenze läuft, damit schneller ist und so was? Sorry, bewege mich da mangels Ahnung auf sehr dünnem Eis.

Mit VBA kenne ich mich weniger aus, aber z.B. unterschiedliche
Excel-Versionen verhalten sich auch unterschiedlich.

Ich wüßte jetzt nicht warum
For x= a To b
in XL2007 schneller laufen sollte als in XL97

Gruß
Reinhard

#6

Hallo Reinhard,

Bis VB4 wurde P-Code verwendet, VB 5 & 6 können P-Code und
Maschinencode erstellen.
Seit .NET wird wieder eine Art P-Code verwendet.

*hüstel* was isssn P-Code? Maschinencode, Assemblersprache ist
mir bekannt, wenn ich sie auch nicht kann.

Pseudo-Code.
Das ist Assemblercode für eine CPU welche es real gar nicht gibt. Dise CPU wird dann von einer realen CPU simuliert.

Du meinst damit daß man im Kompiler einstellt dass z.B. Code
nur innerhalb einer 64 KByte Grenze läuft, damit schneller ist
und so was? Sorry, bewege mich da mangels Ahnung auf sehr
dünnem Eis.

Moderne CPUs bestehen aus unterschiedlichen Einheiten, welche getrennt voneinander arbeiten können.
Zudem werden bedingte Sprünge schon ausgeführt, bevor das Ergebnis für die Bedingung vorliegt.Auch wenn man falsch geraten hat, ist man dann immer noch so schnell, wie wenn man auf das Resultat gewartet hätte.

Je nachdem wie man die Assemblerbefehle anordnet, bekommt man unterschiedlich schnellen Code.

Desweiteren kann man auch den Code umstellen oder aufdröseln:
Aus:
FOR a = 0 TO 10
NEXT a
kann ein moderner Compiler
a = 10
machen. Falls a nur lokal verwendet wird und nach NEXT nicht mehr verwendet wird, kann der Compiler die Schleife gleich ganz weglassen.

Aus
FOR a = 1 TO 2
PRINT a
NEXT a
Kann so auch
PRINT 1
PRINT 2
werden, besonders wenn das schneller ist und erst noch weniger Code erzeugt.

MfG Peter(TOO)

#7

Hallo Reinhard,

Vba wird doch auch kompiliert und nicht zur laufzeit
interpretiert?

??? wann? Nö. Du schreibst den Code und startest ihn … der wird IMO interpretiert, wie VBS.

Gruß, Rainer

#8

Vba wird doch auch kompiliert und nicht zur laufzeit
interpretiert?

??? wann? Nö. Du schreibst den Code und startest ihn … der
wird IMO interpretiert, wie VBS.

Hallo Rainer,

da war ich falsch informiert, du hast Recht, Wikipedia sagt:

…

VBA ist eine interpretierte Programmiersprache, deren Syntax größtenteils mit Visual Basic identisch ist, jedoch ist VBA gegenüber Visual Basic in seinen Funktionen und in der Leistungsfähigkeit seiner Entwicklungsumgebung reduziert.
Beispielsweise wird ein VBA Skript zwar vorkompiliert um Variablen- und Konstantentabellen aufzubauen und syntaktische Überprüfungen durchzuführen, ein Kompilieren bis hin zu ausführbarem Maschinencode ist jedoch nicht möglich.

…
(Quelle: http://de.wikipedia.org/wiki/Visual_Basic_for_Applic… )

Gruß
Reinhard

#9

Hallo,

VB wird compiliert, da spielt es zur Laufzeit keine Rolle mehr
wie lange die Variablennamen einmal waren.

es war auch nicht die Rede von Variablennamen sonder von der Deklaration der Variablen! Und da spielt es wohl eine Rolle ob man eine Variable als short int, long int, int oder double oder was auch immer deklariert.

So ist es in VB(A) moeglich eine Schleifenvaribale als Double oder auch als Dezimal zu deklarieren, und dann geht die Verarbeitungszeit der Schleife ganz enorm in die Kmie.

Tschau
Peter

#10

Hallo,

VBA kompiliert jedes Modul vor der Ausführung, es ist also kein reiner Interpreter, obwohl man keine ausführbaren Dateien erhält.

Gruß, Bernd

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#11

Hallo Bernd,

VBA kompiliert jedes Modul vor der Ausführung, es ist also
kein reiner Interpreter, obwohl man keine ausführbaren Dateien
erhält.

der Quellcode wird jedes mal kompiliert? Das erklärt die Klagen, daß große Programme so lang benötigen, bis sie starten. Danke!

Gruß, Rainer

#12

VBA kompiliert jedes Modul vor der Ausführung, es ist also
kein reiner Interpreter, obwohl man keine ausführbaren Dateien
erhält.

der Quellcode wird jedes mal kompiliert? Das erklärt die
Klagen, daß große Programme so lang benötigen, bis sie
starten. Danke!

Hallo Rainer,
jetzt weiß ich gar nix mehr :frowning:
Ist nun VBA ein Kompiler oder ein Interpreter, oder ein halber Kompiler wo der Rest zur Laufzeit interpretiert wird?
Ich weiß, uralt Basic war Interpreter, dann hatte ich irgendwann eine qbasic Version, die .Exe Dateien erstellen konnte, war die Version qb4.5.
Von daher und auch aus anderen Gründen schloß ich daß auch Vba kompiliert und nicht interpretiert.

Und nu, weiß ich nix mehr was gilt, weiß jmd. wie es wirklich ist?

Danke ^ Gruß
Reinhard

#13

Hallo Reimhard,

jetzt weiß ich gar nix mehr :frowning:
Ist nun VBA ein Kompiler oder ein Interpreter, oder ein halber
Kompiler wo der Rest zur Laufzeit interpretiert wird?

Ich habs für eine Interpretersprache gehalten, Bernd sagt, es wird beim Start kompiliert. Nun habe ich noch mal genau bei Wiki gelesen …

VBA ist eine **interpretierte Programmiersprache** , deren Syntax 
größtenteils mit Visual Basic identisch ist, jedoch ist VBA gegenüber 
Visual Basic in seinen Funktionen und in der Leistungsfähigkeit seiner 
Entwicklungsumgebung reduziert. Beispielsweise wird ein VBA Skript 
zwar **vorkompiliert** um Variablen- und Konstantentabellen aufzubauen und
syntaktische Überprüfungen durchzuführen, ein Kompilieren bis hin zu 
ausführbarem Maschinencode ist jedoch nicht möglich.

Nun weiß ichs’s auch nicht mehr so recht, das klingt nach dem ‚P-Code‘ von VB4. Eine ‚Arbeitsversion‘ des geprüften Quellcodes, die keine Kommentare mehr enthält, Variablennamen durch eindeutige, interne Bezeichnungen ersetzt, aber im Grunde doch interpretiert wird. Schneller Maschinencode scheint es nicht zu sein. So etwas läuft stabiler und schneller als ein reiner Interpreter, aber langsamer als ein Kompilat und startet langsamer als alle anderen, weil der P-Code beim Start erzeugt werden muss … bei jedem Start.

Ich weiß, uralt Basic war Interpreter, dann hatte ich
irgendwann eine qbasic Version, die .Exe Dateien erstellen
konnte, war die Version qb4.5.
Von daher und auch aus anderen Gründen schloß ich daß auch Vba
kompiliert und nicht interpretiert.

Die Bescheibung im Wiki deutet auf ein Zwischending hin, das bis VB4 auch für VB verwendet wurde, so alt ist VBA ja auch. In VB4 wurde der P-Code aber nur ein mal erzeugt und als .exe abgespeichert, obwohl es keine richtige war. :smile:

Gruß, Rainer

#14

Hallo,

teste mal

Sub kompilieren()
 If a Then

End Sub

Du erhälst einen „Fehler beim Kompilieren“ :smile:

Gruß, Bernd

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

1 Like
#15

Hallo Bernd,

teste mal

Sub kompilieren()
 If a Then
End Sub

Du erhälst einen „Fehler beim Kompilieren“ :smile:

ja, korrekt! :smile: Du hast völlig Recht!

Gruß, Rainer

#16

Hallo zusammen,

hätte nicht gedacht dass der Thread so lang wird. Und jetzt noch mein Senf:

Wie schon erwähnt wird nicht „kompiliert“. Prüfung der Syntax, mehr nicht.

Kleines Experiment: Starte ein VBA Progrämchen (das sich „kompilieren“ läßt :wink:) und baue einen Break ein. Dann schnell was ändern und weitermachen lassen. Bei einem kompilierten Code ist das eben nicht möglich. Der Interpreter nimt einfach die nächste Zeile und macht weiter.

Habs mit einer MsgBox getestet. Prompt rein, dort stoppen, Prompt ändern und wundern!

Klar, es gibt auch VB (z.B. VB.Net) das kompliliert wird, aber hier gings ja um VBA.

mfg

Dirk.Pegasus

#17

Hallo Dirk,

hätte nicht gedacht dass der Thread so lang wird. Und jetzt

ich hasse lange Threads wegen der Übersicht wer wann was schrieb.
Aber da es mein Thread ist freue ich mich über jeden Beitrag, kann ja nur lernen davon.

Wie schon erwähnt wird nicht „kompiliert“. Prüfung der Syntax,
mehr nicht.
Kleines Experiment: Starte ein VBA Progrämchen (das sich
„kompilieren“ läßt :wink:)

Aha, erwischt, es wird doch kompiliert :smile:

und baue einen Break ein. Dann schnell
was ändern und weitermachen lassen. Bei einem kompilierten
Code ist das eben nicht möglich. Der Interpreter nimt einfach
die nächste Zeile und macht weiter.

Im Uraltbasic konnte ich auf meinem Sinclair Spectrum ein basic-Programm starten und zur Laufzeit mittels „Poke“ im Programm, genauer in den Bytes des Programms im Arbeitsspeicher, selbst etwas ändern. Machte natürlich nur Sinn für Programmcodesegmente wo der Interpreter erst noch hinkam.

Und, es machte aus Schnelligkeitsgründen schon Sinn, aufgrund der Auswertung einer If Abfrage wurde z.B. der gesamte Code danach gelöscht und ein Exit Sub eingetrgaen und solche Dinge.
Naja, blödes Beispiel, aber ich denke verständlich, jetzt nicht daß es blöde ist sondern aufzeigen der Möglichkeiten.

Und, man konnte in dem Basicprogramm, für bestimmte, zeitaufwendige Dinge, Assemblercode Byteweise durchführen lassen. geht das mit
VB bzw. VBA auch?

Soweit ich weiß, sind C, VB, VBA sogenannte Hochsprachen, Hoch bedeute weit erhöht von dem Prozesor der nur Einser und Nullen kapiert.
Assembler=Maschinensprache ist da systemnäher und deshalb schneller.

Kann man also, wenn man die Assembler Bytefolge kennt um z.B. „Hello World“ am Bildschirm auszugeben, diese in den Arbeitsspeicher schreiben und dann starten? (mit VBA,VB)

Ich erinnere mich dunkel daß dies mit UraltBasic ging, irgendwie mit /w hat man die Bytefolge in den Speicher geschrieben, dann mit /n benannt und dann diesen Namen gestartet.

Danke ^ Gruß
Reinhard

#18

Hallo Reinhard,

Im Uraltbasic konnte ich auf meinem Sinclair Spectrum ein
basic-Programm starten und zur Laufzeit mittels „Poke“ im
Programm, genauer in den Bytes des Programms im
Arbeitsspeicher, selbst etwas ändern.

das geht auch bei tatsächlich nur interpretiertem Code wie VBS nicht mehr. Seit Multitasking kennst Du die Speicheradresse gar nicht mehr und darfst auch nicht mehr direkt in den Speicher schreiben. Die Art zu programmieren ist mit Multitasking nicht mehr möglich.

Gruß, Rainer

#19

Nachfrage

das geht auch bei tatsächlich nur interpretiertem Code wie VBS
nicht mehr. Seit Multitasking kennst Du die Speicheradresse
gar nicht mehr und darfst auch nicht mehr direkt in den
Speicher schreiben. Die Art zu programmieren ist mit
Multitasking nicht mehr möglich.

Hallo Rainer,
wenn du eine vb.exe startest kannst du nicht durch sie ermitteln wo sie im Arbeitsspeicher steht und dann ggfs. was ändern an den Bytes?
Gruß
Reinhard

#20

Hallo Reinhard,

wenn du eine vb.exe startest kannst du nicht durch sie
ermitteln wo sie im Arbeitsspeicher steht und dann ggfs. was
ändern an den Bytes?

nein. Erstens findest Du das nicht und zweiten ergäbe das einen Bluescreen, das erlaubt Windows nicht. Die Zeiten sind vorbei. :smile:

Gruß, Rainer