Softpicks.Net Deutsch

Hallo Michael und alle,

Michael Zimmermann tippelte am 19.09.2006 14:26 in die Tastatur:
> Merksatz:
>
> Jeder Wert einer Eigenschaft oder eines
> Funktionsergebnisses und jeder Objektverweis,
> der öfter als einmal gebraucht wird, ist einer
> typstrengen Variablen zuzuweisen.

ok, gedruckt, ausgeschnitten und gerahmt )

Im Ernst: Man sollte offensichtlich öfter mal so'ne auf den ersten Blick
simplen Fragen fragen... :-)

Norbert

--
Bitte nur in die Newsgroup antworten.
Bei PM bitte nospam durch info ersetzen.
.

[bplumhoff@gmail.com]

Hi Michael,

ich verstehe Dich (denke ich), aber ich stimme Dir nicht 100%-ig zu :-)

Bei Excel kommen wahrscheinlich weniger Ewigkeitswerte als bei jeder
anderen Programmierumgebung zum Tragen. Aeltere Excel-Freunde wie ich
erinnern sich sicher gern an die Excel 4 Makrosprache und das deutsche
Excel-Basic.

Die schliesst aber den Einsatz gesunden Menschenverstandes (und
fundierten Studienwissens) nicht aus. Was wir ja taten, denke ich.

Have fun,
Bernd

.

[Michael Zimmermann]

Hallo!

bplumhoff [at] gmail.com:
> Aber ohne grosse Aufregung kann man denke ich immer
> empfehlen: Ausprobieren, Laufzeit messen, selbst
> optimieren.

Damit kann man auch auf die Nase fallen. Eine typische
Laien-Performance-Messung wird auf der naiven Annahme
fußen, daß es genügt, Endezeit minus Anfangszeit zu
rechnen.

Da dann beim Vergleich einer Anweisung mit einer anderen
nichts rauskommt, weil viel zu schnell, wird man das ganze
in ein For-Next mit vielen Durchläufen stellen.

Jeder Physiker wird bestätigen, daß ein solcher Meßaufbau
nicht sonderlich aussagekräftig ist.

Zunächst müßten Störgrößen nach Möglichkeit eliminiert
werden, z. B. wäre in dem Aufbau

For i = 1 To 100000
'Methode A
Next i

For i = 1 To 100000
'Methode B
Next i

die Laufzeit von

For i = 1 To 100000

Next i

zu bestimmen und bei beiden abzuziehen.

Nur mal angenommen, man mißt A 1000 ms, B 900 ms ("Na, das
ist ja kaum schneller."), aber dann: Leerlauf 850 ms.
Also A eigentlich nur 150 ms, B 50 ms ("Huch, das ist ja
um einen Faktor 3 schneller!")

Zudem muß man diesen Meßapparat oft genug laufen lassen,
sachgerechte Intervalle bilden, mittleren Feler und
Größtfehler bestimmen; eben das übliche Prozedere bei
einer Fehlerrechnung, wie es in einem Meßpraktikum
vermittelt wird.

Man muß ja bedenken, daß bei einer Messung das
Betriebssystem vielleicht gerade mit einem Hintergrundprozeß
den Prozessor belastet oder die Speicherbelegung optimiert
etc. Das kann auf die Laufzeit erhebliche Auswirkungen
haben.

Aus Sicht der Informatik ist das Ergebnis dann im Zweifel
immer noch wenig erhellend.

Angenommen, die beiden zu vergleichenden Anweisungen wären
eine Linearsuche und eine Binärsuche.

Man macht sich ein sortiertes Testarray mit 4 Elementen
und sucht nach beiden Methoden, indem man das in einer
Schleife 10000mal wiederholt. Oh Wunder, die Linearsuche
ist schneller. Kunststück: Wegen des wesentlich einfacheren
Codes ist ein LS-Durchlauf in der Tat schneller als ein
BS-Durchlauf. *Aber*: Wenn man die Suche auch ohne Schleife
drumherum auf ein Array mit 65000 Elementen anwendet,
sieht das ganz anders aus:

Für 65536 Elemente braucht der Lineare Algorithmus im Mittel
32768 Schritte. Bei einer Verdoppelung der Datenmenge
verdoppelt sich auch die durchschnittlich benötigte Anzahl
der Suchschritte.

Für 65536 Elemente braucht der Binäre Algorithmus maximal
16, im Mittel 8(!) Schritte. Bei einer Verdoppelung der
Datenmenge kommt nur ein (1!) Suchschritt hinzu.

Erwartungsgemäß ist jetzt der Binäre Algorithmus um
Größenordnungen schneller.

Die Performance eines Algorithmus beurteilt sich also
nicht allein aus messungen, sondern aus theoretischen
Überlegungen zur Zeitkomplexität einer Anweisungsfolge.

Für eine einzelne Anweisung wie im aktuellen Beispiel
liefert eine schlichte Messung durchaus einen Anhaltspunkt,
da hast Du natürlich recht.

Als allgemeines Prinzip, das man uneingeschränkt empfehlen
könnte, ist das aber nicht ausreichend. Ein Experiment
liefert Erkenntnis, die über bloß enzyklopädisches Wissen
hinausgeht, nur dann, wenn es in einen theoretisch
fundierten Rahmen eingebettet ist.

Muß ja mal ein bißchen Werbung für so schöne Studiengänge
wie Mathematik, Physik und Informatik machen, die dem Leben
erst den rechten Sinn geben. ;-)

Gruß aus Mainz
Michael


.

[Michael Zimmermann]

Hallo!

bplumhoff [at] gmail.com:
> ich verstehe Dich (denke ich), aber ich stimme Dir nicht
> 100%-ig zu :-)

Das bedingt sich auch nicht wechselweise.

> Bei Excel kommen wahrscheinlich weniger Ewigkeitswerte
> als bei jeder anderen Programmierumgebung zum Tragen.

Excel ist als "Mathematikprogramm" auf einem vergleichsweise
hohen Level angesiedelt. Bedenke: Auch Word und Powerpoint
verfügen über VBA...

> Aeltere Excel-Freunde wie ich erinnern sich sicher gern
> an die Excel 4 Makrosprache und das deutsche Excel-Basic.

'Gern' ist wohl ironisch?

> Die schliesst aber den Einsatz gesunden
> Menschenverstandes (und fundierten Studienwissens) nicht
> aus.

Schließen sich nicht gesunder Menschenverstand und
fundiertes Studienwissen manchmal gegenseitig aus?
;-)

Gruß aus Mainz
Michael


.

[Michael Schwimmer]

Hallo Bernd,

<bplumhoff [at] gmail.com> schrieb:

> Sorry, da war ein fataler Wurm drin:
> Die Zeiten von If und Case waren vertauscht.
>
> Richtig ist, was Melanie auch meinte: Die Case Anweisung ist
> schneller, nach meiner Messung etwas mehr als doppelt so schnell.

NACK

Mit der richtigen Verschachtelung und dem Vermeiden von AND/OR (es
werden immer alle Bedingungen überprüft, egal, ob die erste
Bedingung schon nicht erfüllt ist) kannst du durchaus schneller sein.
In dem Bleistift ist eine Gleichverteilung angenommen.

Select Case 26 Sekunden, If Then .. 23 Sekunden

Sub Vergleich()
Dim dtmBegin As Date
Dim dtmEnd As Date
Dim strTime1 As String
Dim strTime2 As String
Dim i As Long
Dim k As Long

' Zeitpunkt Schleifenbeginn speichern
dtmBegin = Time
For i = 1 To 5000000
For k = 0 To 30
'Vergleich durchführen
Select Case k
Case 0 To 10
k = k
Case 11 To 20
k = k
Case 21 To 30
k = k
End Select
Next
Next
' Zeitpunkt Schleifenende speichern
dtmEnd = Time
' Zeitbedarf speichern
strTime1 = "Zeit 'Select case' = " & _
Format(dtmEnd - dtmBegin, "s ""Sekunden""")



dtmBegin = Time
For i = 1 To 5000000
For k = 0 To 30
If k < 10 Then
If k > 0 Then k = k
Else
If k < 21 Then
If k > 10 Then k = k
Else
If k < 31 Then
If k > 20 Then k = k
End If
End If
End If
Next
Next
' Zeitpunkt Schleifenende speichern
dtmEnd = Time
' Zeitbedarf speichern
strTime2 = "Zeit 'If Then' = " & _
Format(dtmEnd - dtmBegin, "s ""Sekunden""")


MsgBox strTime1 & vbCrLf & strTime2

End Sub

Das kann man noch etwas optimieren (26 Sekunden vs. 21 Sekunden):

For i = 1 To 5000000
For k = 0 To 30
If k < 10 Then
If k > 0 Then k = k
Else
If k < 21 Then
k = k
Else
If k < 31 Then
k = k
End If
End If
End If
Next
Next

Noch etwas mehr optimiert (26 Sekunden vs. 18 Sekunden):

For i = 1 To 5000000
For k = 0 To 30
If k < 10 Then
If k > 0 Then k = k
ElseIf k < 21 Then
k = k
ElseIf k < 31 Then
k = k
End If
Next
Next

Bei wenigen Vergleichen würde ich aber immer Select Case vorziehen,
lediglich bei Zeitkritischen Anwendungen If Then.

Wichtig beim Optimieren ist natürlich auch, zu wissen, welche Werte am
häufigsten vorkommen.

MfG
Michael



--
Michael Schwimmer http://michael-schwimmer.de
Excel VBA ISBN 3-8273-2183-2
Excel Programmierung - Das Handbuch ISBN 3-8606-3548-4
.

[Michael Schwimmer]

Hallo Melanie,

"Melanie Breden" schrieb:
> ich tendiere auch zur Select Case-Anweisung, weil sie wesentlich
> übersichtlicher ist und zudem der zu überprüfende Wert nur ein mal
> angegeben werden muss. Die einzelnen Case-Abschnitte können
> ausserdem viel einfacher ausgedrückt werden.
>
> Die Geschwindigkeit dürfte in diesem Beispiel minimal zugunsten von
> Select Case ausfallen, weil in den If- und ElseIf Abfragen jedesmal
> zuerst Vergleiche berechnet werden müssen..

der Knackpunkt dabei ist das AND. Es werden immer alle Bedingungen
überprüft, egal, ob die erste Bedingung schon nicht erfüllt ist.
Siehe mein anderes Posting als Re von Bernd.

Du hast aber recht, Select Case ist weitaus übersichtlicher und nur in
wenigen (zeitkritischen) Fällen macht es Sinn, darauf zu verzichten.

Mit freundlichen Grüssen
Michael

--
Michael Schwimmer http://michael-schwimmer.de
Excel VBA ISBN 3-8273-2183-2
Excel Programmierung - Das Handbuch ISBN 3-8606-3548-4
.

[bplumhoff@gmail.com]

Hallo Michael,

ich habe die vorliegenden Beispiele gemessen.

Allgemein wuerde ich auch bei zeitkritischen Anwendungen zuerst einen
optimalen Algorithmus einsetzen, dann Besonderheiten der vorliegenden
Programmierumgebung ausnutzen (Dein Beispiel If vs. Case) und
schliesslich ggf. eine andere schnellere Umgebung verwenden (C++, C#,
etc.).

Ich bin weiter der Meinung, dass ohne weitere Kenntnis ueber die
Haeufigkeiten IF, CASE und GOTO eigentlich gleich schnell sein sollten.
Deshalb wuerde ich - wenn es nicht sein muss - meine Anwendung nicht
auf Excel 4, Excel 95, Excel 2002 oder Excel *Version XYZ* ausrichten.

Have fun,
Bernd

.

[bplumhoff@gmail.com]

Hi Michael,

Michael Schwimmer wrote:
....
> Case ist definitiv langsamer als If, probiere es doch mal mit nur einer
> Bedingung (If vs. Case Else) aus.
....

Ja, in Excel VBA. Das ist (leider) so, sollte aber nicht so sein.
Eigentlich muesste IMHO Excel's intermediate code fuer alle identisch
sein (Cascade If = Case = Goto).

Aber: Es ist mir auch egal. Wenn ich ein Laufzeitproblem habe, messe
ich, wo ich es habe. Dann gucke ich, ob mein Algorithmus dort
verbessert oder veraendert werden kann.

OT: Das Ideenklau-Problem hatte ich bisher nicht. Wenn ich meinen Code
verstecken muesste, dann wuerde ich ihn natuerlich auch auslagern.

Have fun,
Bernd

.

[Michael Schwimmer]

Hallo Bernd,

<bplumhoff [at] gmail.com> schrieb:

> Allgemein wuerde ich auch bei zeitkritischen Anwendungen zuerst einen
> optimalen Algorithmus einsetzen, dann Besonderheiten der vorliegenden
> Programmierumgebung ausnutzen (Dein Beispiel If vs. Case) und
> schliesslich ggf. eine andere schnellere Umgebung verwenden (C++, C#,
> etc.).

Na ja, ob C# wirklich so schnell ist, sei dahingestellt. Ich habe in
VB.Net ein Programm geschrieben, mit dem ich alle
Buchstabenkombinationen gegebener Buchstaben daraufhin teste, ob sie in
einem Wörterbuch (in Textform) vorkommen.

Ich wollte schneller sein als unter VBA und habe alles mögliche
probiert, sogar Multithreading eingesetzt, aber bei Textvergleichen
scheint .Net hoffnungslos unterlegen zu sein.

Und das, was bei der Erstellung der Exe im Endeffekt herauskommt, dürfte
auch unter C# nicht viel anders aussehen.

Zudem kommt das Programmieren unter C#, C++ oder Objektpascal für den
Normalanwender nicht in Frage. Selbst das Benutzen der erstellten
Bibliotheken dürfte dem meisten Anwendern verwehrt bleiben.

> Ich bin weiter der Meinung, dass ohne weitere Kenntnis ueber die
> Haeufigkeiten IF, CASE und GOTO eigentlich gleich schnell sein
> sollten. Deshalb wuerde ich - wenn es nicht sein muss - meine

Case ist definitiv langsamer als If, probiere es doch mal mit nur einer
Bedingung (If vs. Case Else) aus.

> Anwendung nicht auf Excel 4, Excel 95, Excel 2002 oder Excel
> *Version XYZ* ausrichten.

Das schöne ist aber, dass nichts zusätzliches installiert werden muss.

Wenn ich etwas kommerziell machen würde, könnte man sich aber überlegen,
ob man Funktionalität auslagert, allein schon wegen "Know How" klau.

Und eigenständige Anwendungen wird man sowieso nicht unter Excel
erstellen, da dies wiederum Excel voraussetzt.


Viele Grüße
Michael

--
Michael Schwimmer http://michael-schwimmer.de
Excel VBA ISBN 3-8273-2183-2
Excel Programmierung - Das Handbuch ISBN 3-8606-3548-4
.

[Michael Schwimmer]

Hallo Eckerhard,

"Dr. Eckehard Pfeifer" schrieb:

> Hallo, kannst Du mal posten, an welchem konkreten Beispiel VB.NET
> langsamer ist als VBA? Das ist mehr als interessant.

http://die-schwimmers.de/vba102.htm

MfG
Michael

--
Michael Schwimmer http://michael-schwimmer.de
Excel VBA ISBN 3-8273-2183-2
Excel Programmierung - Das Handbuch ISBN 3-8606-3548-4
.