Das Notes Forum
Best Practices => Diskussionen zu Best Practices => Thema gestartet von: TMC am 09.04.04 - 19:54:22
-
Ich starte mal einen Thread bezüglich Performance in Lotus Notes.
Anlass ist u.a. dieser Thread:
http://www.atnotes.de/index.php?board=9;action=display;threadid=15109
Heute habe ich mich gefragt, ob es performance-seitig einen Unterschied macht, ob man Dokumente einer View
a) über NotesViewNavigator
oder
b) über NotesViewEntryCollection
abarbeitet.
Code-Auszug für a):
Dim nav As NotesViewNavigator
Set nav= view.createViewnav()
Set viewentry=nav.GetFirstDocument
Do While Not (viewentry Is Nothing)
(......)
Set viewentry = nav.getnextdocument(viewentry)
Loop
Code-Auszug für b):
Dim vc As NotesViewEntryCollection
Set vc = view.AllEntries
Set viewentry = vc.GetFirstEntry()
Do While Not (viewentry Is Nothing)
(......)
Set viewentry = vc.GetNextEntry(viewentry)
Loop
Testumgebung:
- Athlon 2600 XP, 512 MB RAM
- Windows XP
- Notes 5.011 LOKAL
- 5.000 Dokumente, die in Excel exportiert werden
Ergebnis:
Ich habe exakt diesselbe Zeit gestoppt bei (a) und (b): 55,2 Sekunden.
Fazit:
Kein Unterschied. Es obliegt also der Entwickler-Freiheit, mit was man lieber arbeitet :-)
Matthias
-
Noch ein Test: Variablen-Deklaration:
Ich habe im selben Script Option Declare ausgeschaltet und 12 Variablen-Deklarationen (Für Integer und String) auskommentiert.
Hier habe ich nur mit 1000 Dokumenten getestet.
Fazit:
Deklarierte Variablen: 12,1 Sekunden
Nicht deklarierte Variablen: 12,4 Sekunden
Matthias
-
Wenn Du schon dabei bist, Matthias, probiere das doch mal mit
NotesView.GetFirst/NextDocument
Da das ja die variante ist, um noch mehr Infos aus Docs in Views zu bekommen, als in der View stehen, wäre der Vergleich wirklich sehr interessant. IMHO sollte da die Performance sogar noch besser sein.
Es kommt aber natürlich immer auch darauf an, was "zwischen den Zeilen" steht, also, was zwischen der Bearbeitung zwischen Doc N und Doc N+1 passiert.
Sehr gespannt,
Bernhard
-
Hier kann ich leider in dem o.g. Testszenario keinen Vergleich liefern, Bernhard, da ich hier mit NotesViewEntry arbeite, und hier in diesem Test mit doc nichts anfangen kann.
Wobei: Intuitiv hätte ich eh mit NotesView.GetFirst/NextDocument gearbeitet, wenn ich das Dokument selbst brauche.
Mal sehen, wenn ich Lust habe, mache ich es umgekehrt, und setze ein Testscript um, um das Viewentry in das doc zu kriegen (und da dann irgendwas damit zu machen).
Dann hätte man was zu vergleichen.....
Matthias
P.S. hochinteressant das Thema :)
-
Ich habe mal in einer Applikation das GetDocument durch das Durchwandern der EntryCollection ersetzt, da die Entry-Collection nur den Index, nicht jedoch die Dokumente zieht, ist die EntryCollection d e u t l i c h schneller, die genauen Daten habe ich nicht mehr, aber das war eine Performance-Verbesserung von 2,5 Std. auf 0,5 Std. herunter. Das Anziehen der Notes-Dokumente scheint enorm teuer zu sein.
-
Nun doch noch ein Vergleich.
Der Vergleich basiert auf
a) NotesViewEntryCollection
b) NotesViewNavigator
c) NotesDocumentCollection
In (a) und (b) wird jeweils eine View bearbeitet, in (c) alle Dokumente der DB.
Unten angehängt eine Beispiel-DB. Da es hier nur 1 View gibt und keine weiteren Doks, werden mit allen 3 Beispielen dieselbem Doks abgearbeitet.
Testen kann nun jeder selbst.
Ich empfehle, per Copy & Paste mehrere 1000 Dokumente zu erstellen, ich habe mal 50.000 erstellt zum testen.
Mein Fazit: (c) war am schnellsten.
Matthias
*Edit*
Ach ja: Aufrufen kann man die einzelnen Scripts in der View über den Button "Neuer Nachname".
-
Interessant, da scheinen die verschiedensten Einflüsse zu gelten, wie zum Beispiel, ob es Differenzen zwischen AllDocuments der DB und dem Durchwandern einer View gibt. Bin nicht mehr sicher, ob ich damals die Dokumente über eine Collection bekommen habe oder anders. Das Problem der Collection gegenüber ViewEntryCollection ist in der Regel die fehlende Sortierung.
-
Jo, ich bin gespannt, ob wir es schaffen, einen "Leitfaden" zu erstellen für Entwickler der vieles abdeckt :D
Das Ergebnis wäre vielleicht eine Matrix / Tabelle.....
Muss ja kein Schnellschuss werden, und alles kann man nicht auf einmal abdecken.
Bin weiter hochinteressiert :)
Interessant fand ich auch das Ergebnis der (Nicht-)Deklaration von Strings etc.
Ein weiterer Grund also, Option Declare einzusetzen :-)
Matthias
-
Hier noch - zur Ergänzung erwähnt - das Performance-Kapitel in der Schleifenkunde:
http://www.atnotes.de/index.php?board=26;action=display;threadid=13504
Siehe da Kapitel 9 .....
-
Ein weiterer interessanter Test:
Ist ein @ReplaceSubstring in Script schneller als ein Evaluate ?
Zum testen siehe unten das Attachment.
Ich habe noch keinen Stoppuhrtest gemacht, aber subjektiv war das Script schneller (!!).
Matthias
-
Ich steig' da morgen ein ! Habe auch ein paar nette richtig grosse "on the wild"-Datenbanken.
Evaluate vs. pure script - auch ein nettes Kapitel.
Ohne jetzt hineingeschaut zu haben (sorry !), befürchte ich aber, dass das LS-Äquivalent von @ReplaceSubstring wieder die "Arme-Leute-Variante" ist, die dann natürlich weniger zu tun hat.
Also: Morgen weiter ! Bei mir wartet gerade noch ein Stapel Arbeit - da gibt es Kunden, denen auch das Osterfest nicht heilig ist ;-)
Ciao,
Bernhard
-
Ohne jetzt hineingeschaut zu haben (sorry !), befürchte ich aber, dass das LS-Äquivalent von @ReplaceSubstring wieder die "Arme-Leute-Variante" ist, die dann natürlich weniger zu tun hat.
Ähm, jo, richtig geraten (nur für String und nicht Array).
Ich habe jetzt noch einen weiteren ReplaceSubstring eingebaut, Quellcode ist von Dir Bernhard, siehe http://www.atnotes.de/index.php?board=11;action=display;threadid=12267
Getestet habe ich jetzt mit 5.000 Dokumenten. Ich habe einen Satz mit ca. 150 Wörtern in das Feld Nachname kopiert. Dann habe ich ein Wort mit 10 Buchstaben, welches im hinteren Drittel des Textes ist, jeweils ersetzen lassen.
Ergebnis:
- Replace Substring (String-basierend): 12 Sekunden
- Replace Substring (Array-basierend): 12 Sekunden
- @ReplaceSubstring mit Evaluate: 15 Sekunden
Matthias
** EDIT **
Unten die aktuelle DB
-
Hier noch ein paar LDD - Artikel:
Evaluate - Performance (http://www-10.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/1b582ddee7c72e10852566ac005f0b99?OpenDocument)
Application Performance Tuning - Part 1 (http://www-10.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/daaae651347c91d285256cf500738560?OpenDocument)
Application Performance Tuning - Part 2 (http://www-10.lotus.com/ldd/today.nsf/a2535b4ba6b4d13f85256c59006bd67d/0c59c2787af5c1a685256d1600552fce?OpenDocument)
Date/Time Views (http://www-1.ibm.com/support/docview.wss?uid=swg27003557)
-
Ähm, jo, richtig geraten (nur für String und nicht Array).
Ich habe jetzt noch einen weiteren ReplaceSubstring eingebaut, Quellcode ist von Dir Bernhard ...
Ergebnis:
- Replace Substring (String-basierend): 12 Sekunden
- Replace Substring (Array-basierend): 12 Sekunden
- @ReplaceSubstring mit Evaluate: 15 Sekunden
Das muss ich ja ganz geschickt programmiert haben, wenn die komplexe Routine so fix ist wie die simple ;D
Bernhard
-
Stimmt :D
Dein Code hat (ohne Comments, Leerzeilen etc.) 123 Zeilen, der String-basierende 6 Zeilen ;D
-
Ist zwar schon ein älterer Thread, aber ich hänge hier mal 2 Links rein zum Thema @Formula-Performance.
Damien Katz: Formula Language's dirty secret (build a list using the list concatenation operator) (http://damienkatz.net/2004/11/formula-languages-dirty-secret.html)
Lotus Geek: Ergänzungen zu Damien's Artikel (http://www.lotusgeek.com/SapphireOak/LotusGeekBlog.nsf/d6plinks/ROLR-66SJQE)