[Dev] Performance

Kalli · 20 Jan. 2007

Hi,
ich habe so das Gefühl, dass das Schrauben am Code, um die Performance, insbesondere beim Starten, zu verbessern, nicht so viel bringt. Man müsste sich zumindest mal anschauen, wie die jeweilige VM arbeitet. Ich habe mal eine kleine Vergleichsmessung beim Exportieren gemacht und auch mal gemessen, wie lange das Laden eines Profils dauert (also CacheWolf war gestartet, ich habe über Anwendung->Profile->Laden ein neues geladen).
Noch ein paar Daten:
- Messmethode: Stopuhr
- Rev. 412
- Datenbank hat 262 Einträge
- Exporter: TomTom .asc in ein File, ASCExporter
- java-Version wurde aus eclipse heraus gestartet
- jre 1.5.0_09
- OS: WinXP Home
- alle Angaben in Sekunden

Code:

Export
Version TomTomASC  ASC
java     1,52      1,20
ewe      8,80      7,59
exe     12,52      9,77

Profil laden
java 1,61
exe  9,83

Wie man sieht, ist der Code, wenn er unter java ausgeführt wird, wesentlich schneller als wenn man eine VM nimmt.

pfeffer · 20 Jan. 2007

vielleicht ist die ewe-vm einfach viel langsamer
vielleicht probiert man mal

* 10000 fach nen sinus zu berechnen - mal mit java, mal mit ewe-vm.
* 1000 mal Dateioperation
* 1000 mal Speicher allokationen
* 1000 mal einen Funktionsaufruf

ich denke, das wären so die wichtigsten sachen. Wir wir davon vergleichwerte hätten, wüssten wir wenigstens, was wir in ewe vermeiden sollten.

Gruß,
Pfeffer.

Kalli · 21 Jan. 2007

Ok, werde ich mal machen. Ich habe mittlerweile eine kleine Testroutine eingbaut, die man beim Statrt durchlaufen lassen kann, da packe ich die Sachen mal rein.

Kalli · 21 Jan. 2007

So, habe die erste Runde gedreht. Hier das Ergebnis:

Code:

Java 30 msec 100000 * sin(53)
Java 406 msec 100 * CWPoint
Java 968 msec 10000 * Filewrite 10 Bytes

Win32 47 msec 100000 * sin(53)
Win32 2047 msec 100 * CWPoint
Win32 594 msec 10000 * Filewrite 10 Bytes

Die File operationen hatte ich also zu Unrecht in Verdacht. Der Aufruf des CWPoint-Konstruktors mit Koordinatenangaben benötigt unter Win32 fünf mal solange wie unter Java. Hiervon machen wir beim Start regen Gebrauch. Ich werde da mal weiterforschen.

salzkammergut · 21 Jan. 2007

@Kalli: Interessante Messungen. Es überrascht mich nicht, daß der CWPoint Konstruktor mit dem Regex sehr langsam ist. Er wird aber beim Laden nicht verwendet. Ich glaube nicht daß er die Ursache für die Ladezeitprobleme ist.

Ich würde gerne wissen was die fixe Zeit beim Laden ist (also wenn CacheAnzahl=0) und was dann je Cache dazu kommt.

Zum Koordinatenparsen noch einige Infos:
Tests bei mir:

Code:

100000 * ParseLatLon Neu (Rev 411) parse       400 msec
100000 * ParseLatLon Alt (vor Rev 411) parse   650 msec
100000 * CWPoint Konstruktor                 26600 msec

Das Parsen der Koordinaten mit ParseLatLon ist wesentlich schneller (aber halt nicht so flexibel).

Kalli · 21 Jan. 2007

Hi,
habe gerade mal mein Test-Modul eingecheckt. Den Start und Profilwechsel bin ich gerade beim Ausmessen.

Kalli · 21 Jan. 2007

So, hier die neusten Ergebnisse:

Code:

Java, 262 Caches
14:05:49.734 Start
14:05:49.765 nach ReadIndex
14:05:50.046 nach updBearDist
14:05:50.468 nach setTablePanel

Java, 0 Caches
14:08:42.000 Start
14:08:42.015 nach ReadIndex
14:08:42.015 nach updBearDist
14:08:42.406 nach setTablePanel

Win32, 262 Caches
14:09:52.359 Start
14:09:52.968 nach ReadIndex
14:09:59.875 nach updBearDist
14:10:00.468 nach setTablePanel

Win32, 0 Caches
14:12:13.906 Start
14:12:13.937 nach ReadIndex
14:12:13.937 nach updBearDist
14:12:14.234 nach setTablePanel

Gemessen wurde an den entsprechenden Stellen in MainForm. Die Zeit wird also in updateBearingDistance verbraten, wobei hier schon die schnelle Version des Parsens genutzt wird. Somit bleibt die Behandlung der addi wpts erst mal drin.

pfeffer · 21 Jan. 2007

was sehr dafür spricht, die Cache-Lat/Lon in einem fest vorgeschriebenen Format zu speichern, das nicht mehr aufwändig geparst werden muss.

Ich war zunächst beim Aufruf der MovingMap zur Anzeige markierter Caches die ganze Liste markierter caches durchgegangen und entsprechend musste ich die LatLan-Strings in CWPoint wandeln. Das hat bei vielen markierten Caches Ewigkeiten gebarucht.
Jetzt habe ich ja .pos in den CacheHolder hinzuigefügt, seitdem macht es überhaupt nichts mehr aus, 300 Caches markiert zu haben und damit die MovingMap aufzurufen...
Ich würde einfach ein dezimales Format wählen - fertig.

Gruß,
Pfeffer.

pfeffer · 21 Jan. 2007

salzkammergut schrieb:

Tests bei mir:

Code:

100000 * ParseLatLon Neu (Rev 411) parse       400 msec
100000 * ParseLatLon Alt (vor Rev 411) parse   650 msec
100000 * CWPoint Konstruktor                 26600 msec

das ist ja irre!
hast Du CWPoint() aufgerufen? - oder den Konstruktor mit irgendwelchen Koordinaten angaben?
dann wäre zu testen: braucht einfach die Speicherallokation so lange?

ich habe mal irgendwo folgenden Tipp gelesen:

Code:

 for(int i = 0; i<cacheDB.size();i++){

sei langsamer als notwendig, weil dadurch bei jedem schleifendurchlauf size() neu aufgerufen werden muss. Wenn die Reihenfolge egal ist, dann ist es leicht, das zu sparen:

Code:

 for(int i = cacheDB.size() -1; i>=0;i--){

Gruß,
Pfeffer.

salzkammergut · 21 Jan. 2007

Der Code für diese Tests war wie folgt:

Code:

		long start = Vm.getTimeStampLong();
		for (int i=0; i<100000; i++) {
			//ParseLatLon p=new ParseLatLon("N 45° 30,234 E 22° 30.789");
			//p.parse();
			CWPoint cw=new CWPoint("N 45° 30.234 E 22° 30.789");
		}
		long end = Vm.getTimeStampLong();
		Vm.debug("Time = "+(end-start));

Auskommentiert ist der andere Test.

salzkammergut · 21 Jan. 2007

@Pfeffer:

Mir erscheint, daß Du die schnelle Anzeige bei der Moving Map gegen eine langsamere Ladezeit getauscht hast weil jetzt beim Laden in updateBearingDistance die ganzen pos Felder durch Parsen befüllt werden müssen.

Ich fände es eigentlich auch gut, wenn in der index.xml die Koordinaten als zwei Dezimalzahlen gespeichert würden (auch wenn der exakte Effekt noch nicht quantifizierbar ist, es bringt sicher was). Sie müssen dann zwar beim Einlesen in das CW-Format umgewandelt werden (was aber mit einer optimierten Routine schneller als Parsen gehen müßte). Dazu würde ich vorschlagen, daß wir in der <CACHELIST> Zeile ein attribut format="decimal" hinzufügen um die Abwärtskompatibilität zu gewährleisten. Durch dieses Attribut braucht man nicht bei jeder Zeile prüfen, welches Format vorliegt. Alte Dateien ohne dieses Attribut werden wie gehabt geparst. Beim Schreiben, wird immer das neue Format erzeugt. Ich habe diesen Code mal eingecheckt.

Auch wäre darüber nachzudenken, ob wir statt pos zwei Felder latDec und lonDec einführen (das spart den CWPoint Konstruktor). Diese Felder sollten eigentlich bereits beim Einlesen erzeugt werden (und nicht in updateBearingDistance), da sie mit den Bearings nichts zu tun haben.

salzkammergut · 21 Jan. 2007

Also etwas bringen die dezimalen Koordinaten - bitte testet es einmal bei Euch.

Ich habe mal eine index.xml Datei mit 194 Einträgen auf etwa 2300 Einträge "vervielfältigt". Die Ladezeit am PC (ab Klick auf OK im Ladedialog bis Beginn Aufbau der Tabelle) hat sich von ca. 3.5 Sekunden auf etwa 2.8 Sekunden reduziert.

Nicht weltbewegend, aber doch ...

pfeffer · 21 Jan. 2007

Code:

Java 62 msec 100000 * sin(53)
Java 188 msec 100 * CWPoint("N 51° 27.635 E 009° 37.621", CWPoint.CW)
Java 126 msec 100 * cwp = new CWPoint(); cwp.set("N 51 27.635 E 009 37.621", CWPoint.CW); 
Java 0 msec 100 * cwp = new CWPoint(); cwP.latDec = 41.123; cwP.lonDec = 9.2388;
Java 124 msec 100 * cwSet.set("N 51° 27.635 E 009° 37.621", CWPoint.CW) CWPoint set
Java 1000 msec 10000 * Filewrite 10 Bytes


Win32 78 msec 100000 * sin(53)
Win32 3109 msec 100 * CWPoint("N 51 27.635 E 009 37.621", CWPoint.CW)
Win32 3000 msec 100 * cwp = new CWPoint(); cwp.set("N 51 27.635 E 009 37.621", C
WPoint.CW);
Win32 0 msec 100 * cwp = new CWPoint(); cwP.latDec = 41.123; cwP.lonDec = 9.2388
;
Win32 2750 msec 100 * cwSet.set("N 51 27.635 E 009 37.621", CWPoint.CW) CWPoin
t set
Win32 687 msec 10000 * Filewrite 10 Bytes

sehr eindrucksvoll. Das setzten von lat/lon ist extrem viel schneller.
ich habe es mit 10.000 mal nochmal getestet in der Java-Vm dauert es 32 ms, in der ewe-vm 67msec.

Ich checke das mal ein

Gruß,
Pfeffer.

pfeffer · 21 Jan. 2007

das bringt bei mir richtig was.
Ich habs nicht gemessen. Aber die Ladezeit hat sich von gefühlten 50 sekunden auf gefühlte 10 verkützt auf meine PDA

super! vielen dank, Salzkammergut!
Ich meine, wir sollten jetz grundsätzlich noch den Code so umstellen, dass String LatLon nicht mehr genutzt wird.

Gruß,
Pfeffer.

salzkammergut · 21 Jan. 2007

Also ich kann das jetzt auch bestätigen. Habe am IPAQ 192 caches eingelesen: Vorher 73 Sekunden, jetzt 13 Sekunden (wobei ich glaube, daß wir schon mal in diesem Bereich waren).

Kalli · 21 Jan. 2007

Habs schon in einem anderen Thread geschrieben, das hat definitiv etwas gebracht. Super Arbeit, Jungs.

Jetzt müsste man mal noch mit ein paar Koordinaten testen, die auch negative Vorzeichen haben, da gabs in der Vergangenheit ab und zu mal Probleme ....

2cachefix · 23 Jan. 2007

Super.
Ich kann das nur bestätigen. Ich habe die Ladezeit der BE417 und BE437 getestet.

Win(BE417) 75
Win(BE437) 5
PPC (BE417) 555
PPCBE437) 60

Angaben jeweils in Sek. bei 1520 Caches.

[Dev] Performance

Kalli

Geowizard

pfeffer

Geowizard

Kalli

Geowizard

Kalli

Geowizard

salzkammergut

Geomaster

Kalli

Geowizard

Kalli

Geowizard

pfeffer

Geowizard

pfeffer

Geowizard

salzkammergut

Geomaster

salzkammergut

Geomaster

salzkammergut

Geomaster

pfeffer

Geowizard

pfeffer

Geowizard

salzkammergut

Geomaster

Kalli

Geowizard

2cachefix

Geomaster