Performance bei der Programmierung einsparen

[bikerboy]

Hallo liebe Kollegen,

Ich haber hier seit Wochen ein Projekt laufen, dass sich im finalen Stand befindet. Es funktioniert also.

Mein Problem ist nun, dass ich wohl leider zu unperformant programmiert habe.

Ich arbeite im Hauptsächlichen Fall mit

NotesDXLExporter
NotesDXLImporter
Strings
und ein paar selbst geschriebenen kleinen Klassen.

Könnt ihr mir sagen, wo so ein paar Performance Fallen lauern, damit ich meinen Code optimieren kann ?

[Felix Ziegler]

Hallo Robert,

ich denke dieser Link wird dir weiterhelfen können:

http://www.jamiemagee.com/jm/jamie.nsf/downloads/JMAE-7XULMY

Wobei natürlich DXLImporter/-Exporter nicht zu den schnellsten Klassen im Notes Bereich zählen ...

Viele Grüße
Felix

[bikerboy]

So habe mal das PDF überpflogen, danke schon mal aber die bösen Fehler habe ich nicht gemacht.

Ich die die exporter und die importer sind nicht schuld.

Laut Profiling ergebnis lasse ich extrem viel zeit beim GetItemValue. Leider werden meine eignen Klassen nicht mit "profilisiert"

[pram]

die verdächtigen Stellen kannst du einfach mit

Code

Dim start
start = Getthreadinfo(6) ' LSI_THREAD_TICKS
.... problematic code
print "Code XXX took" , Getthreadinfo(6)  - start, "ms"

stoppen. LSI_THREAD_TICKS hat eine Auflösung von ~16ms. Falls dir das nicht reicht um die Problemstellen aufzuzeigen kannst du

Code

Declare Private Function QueryPerformanceFrequency	Lib "Kernel32" (X As Currency) As Boolean
Declare Private Function QueryPerformanceCounter		Lib "Kernel32" (X As Currency) As Boolean

verwenden. Dieser hat eine wesentlich höhere Auflösung.

Wir haben uns hierfür eine kleine Klasse (profiler) gebaut, welche im Konstruktor und Destruktor die Zeit misst und dann protokolliert wie lang das Objekt gelebt hat.
Man kann dann mit einem Einzeiler die Zeit stoppen, die man in einer Methode braucht:

Code

public function anyFunction()
  dim p as new Profiler("infotext") ' wenn die GarbageCollection das Objekt löscht, muss die Zeit ausgegeben werden.
  ... rest of code
end function

Wenn du dann deine problematischen Methoden gefunden hast, dann kannst ja mal Codeausschnitte posten.

Gruß
Roland

[DerAndre]

Hmmm, Profiling. Schönes Thema.
Habe ich auch gerade an den Füssen, da wir hier einige Dinge haben die extrem Lange brauchen.
Einen Übeltäter habe ich schon, lässt sich wohl leider ohne weiteres nicht ändern. Eine engebettete Ansicht auf eine andere DB. Böööööse Falle... Nun gut. mal schauen, ob man das mit anderen Mitteln ändern kann.
Aber diese Profilingklasse hört sich gut an.

[DerAndre]

So. Habe das Folgende in meiner Notes.ini eingetragen

Client_Clock=1
Debug_Console=1
Debug_Outfile=<path to filename>


scheint aber nicht mehr zu funktionieren, das Debugfenster ist leider nicht sehr gesprächig. ( Notes 7.0.3 ), kann das jemand bestätigen?

Funtioniert, nur mal wieder nicht bei mir... 

[m3]

*hüstel*
<path to filename>
*hüstel*

[DerAndre]

Da setht bei mir c:\temp\log.txt

Das Problem ist aber, daß das Debugfenster keinen Piep sagt...

Ganz so deppert bin ich nu auch nicht 

So

Oder so

Wie gesagt, mein Client mag mal wieder nicht.

[m3]

Angesehen davon, was hilft die die Info, dass der oder der Call länger braucht? Für die Anwendung wirst Du ja nicht ein neues Netzwerk, neue Server, ... bekommen, oder?

Ist dir eigentlich schon klar "WAS" an Deiner Anwendung "langsam" ist? Irgendwie kommt mir vor, als würdest Du ohne Plan herumstochern, oder?

[pram]

Ich glaube mit dem Eclipse-Client geht das mit dem Debug-Window nicht mehr...

@m3
Wenn man mal die langsamen Calls gefunden hat, kann man sich ja immer noch Lösungen überlegen ob der Call notwendig ist, bzw. durch Caching von Zwischenergebnissen was verbessern kann. (Wobei ich mir NICHT vorstellen kann, das ein GetItemValue der Performance-Killer ist)

Gruß
Roland

[DerAndre]

Martin, wen meinst Du?

[bikerboy]

Also ich bedanke mich erstmal für die anrengende Diskusion.

Habe das Problem mit ein paar prints relativ schnell einfangen können.

Erst hat eine Funktion die eh nicht richtig funktionierte knappe 20 Sekunden gebraucht, diese habe ich einfach gelöscht und deren funktionalität in einer anderen Funktion eingefügt, die sowieso schon alle nötige Werte im ZUgriff hat.

Dann war meine eigene Klasse noch ein Problem unter anderen bin ich mit einem DB.Search auf die Datenbank los. Als ich das schon geändert habe, konnte ich noch einiges gut machen.

Als letztes habe ich dreimal den Exporter losgetreten, weil ich die zu exportierenden Felder im einzelnd in nem neuen Dokument exportiert habe. Ich habe dann einfach das vorhandene exportiert und mir per strleft und strRight die passenden Werte gezogen, und schon braucht der Konstruktor nicht mehr 2 Sekunden sondern nur noch einen Bruchteil.

Als Krönung habe ich eine Liste mit bereits verwendeten Objekten meiner Klasse erstellt, heisst, wenn ich das Objekt nochmal brauche schaue ich einfach schnell in die Liste und habe das Dokument wieder, ohne den Konstruktor nochmal aufzurufen.