... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Performance Löschen
#1
Hallo Christian,

am Wochenende habe ich mal versucht etwas meine Monsterdateien abzuspecken.
Wenn ich bei dem Track mit 580.000 Punkten den Douglas-Peucker laufen lasse, so benötigt der etwa 1,5 Stunden zum markieren von 560.000 Punkten.
Das ist für mich noch OK, da da ja eine Menge gerechnet werden muss.

Was mich jetzt allerdings etwas irretiert ist, dass das Löschen anschliessend fast 8 Stunden benötigt und dabei sich der Speicherverbrauch fast vervierfacht. Subjektiv war ich auch der Meinung, dass das schneller geht, wenn ich meinen DSL-Router ausschalte.

Daher die Frage - kannst Du mal in den Code schauen, obs da etwas Optimierungspotential gibt ? Evtl. wird nach jedem gelöschten Punkt irgendein refresh ausgelöst, auf den man verzichten könnte. (Höhenprofil o.ä.)

Gruß
Thomas

P.S.: was genial wäre: wenn der Dialog nicht in der Zeit den Swing-Thread blockieren würde und stattdessen einen irgendwie gearteten Fortschritt anzeigen könnte - "schon x Positionen gelöscht" oder so.
Reply
#2
(26.11.2012, 06:11)lundefugl Wrote: Daher die Frage - kannst Du mal in den Code schauen, obs da etwas Optimierungspotential gibt ? Evtl. wird nach jedem gelöschten Punkt irgendein refresh ausgelöst, auf den man verzichten könnte. (Höhenprofil o.ä.)

Das ist in der Tat so. Ich fasse in ConvertPanel#selectPositions() schon Events für aufeinanderfolgende Indices zusammen, um die Anzahl der Events zu minimieren. Leider ist das Selektionsgehampel von DeletePositionsDialog#handlePositionsUpdate und ConvertPanel#handlePositionsUpdate immer noch ziemlich teuer.

(26.11.2012, 06:11)lundefugl Wrote: P.S.: was genial wäre: wenn der Dialog nicht in der Zeit den Swing-Thread blockieren würde und stattdessen einen irgendwie gearteten Fortschritt anzeigen könnte - "schon x Positionen gelöscht" oder so.

Das Selektieren, das die meiste Zeit kostet, muß in der AWT-Eventqueue ausgeführt werden. Da hilft wohl nur der Einbau eines ProgressMonitor in ConvertPanel#selectPositions() wie in BatchPositionAugmenter um dem Nutzer eine Chance zum Abbrechen zu geben und den Fortschritt zu visualisieren.
--
Christian
Reply
#3
Hallo Thomas,

versuche das Ganze (Douglas-Peucker ) mal mit GpsPrune und vergleiche mal die Zeiten. Ich habe zwar nur ca. 30 000 Punkte aber da ist keine Verzögerung zu merken. Eventuell kann man von da was übernehmen. Ist glaube ich auch Java.

Sorry, ich möchte aber niemand von Routeconverter weglotsen. Ich mache das mit AVGPS das ist ein .NET C# Programm. Leider hat der Autor die Weiterentwicklung aufgegeben. Aber die Zeiten von DP von oben erscheinen mir utopisch......

Grüsse
Achim

Ps: Dort kann man auch mehrere Tracks laden......

Ich habe eben mal mehrer Tracks geladen (ca. 250000 Punkte) und (Ge)Peuckert (Reduktion auf ca2000 Punkte) mit nahezu keiner merklichen Verzögerung!
Grüsse Achim
Reply
#4
(26.11.2012, 16:59)womisa Wrote: versuche das Ganze (Douglas-Peucker ) mal mit GpsPrune und vergleiche mal die Zeiten. Ich habe zwar nur ca. 30 000 Punkte aber da ist keine Verzögerung zu merken. Eventuell kann man von da was übernehmen. Ist glaube ich auch Java.

Ich hatte das vielleicht nicht deutlich genug geschrieben: die Rechenleistung für Douglas-Peucker ist nicht das Problem sondern das Selektieren von Karte und Profil. Da kann man nichts von Prune übernehmen.

(26.11.2012, 16:59)womisa Wrote: Sorry, ich möchte aber niemand von Routeconverter weglotsen.

Tust Du ja doch, aber das ist gar nicht schlimm: es geht ja darum, eine Lösung zu finden. Und RouteConverter an der Stelle zu optimieren ist nicht trivial.

(26.11.2012, 16:59)womisa Wrote: Aber die Zeiten von DP von oben erscheinen mir utopisch......

Wie gesagt: die Rechenleistung für Douglas-Peucker ist nicht das Problem sondern das Selektieren von Karte und Profil.
--
Christian
Reply
#5
Hallo Christian,

(26.11.2012, 17:07)routeconverter Wrote: Wie gesagt: die Rechenleistung für Douglas-Peucker ist nicht das Problem sondern das Selektieren von Karte und Profil.

was evtl. auch eine Möglichkeit wäre ist, dass man die Selektion per Checkbox oder versteckte Option ganz abschalteten kann. GGf. dann "markieren" und löschen in einem Rutsch macht.

Zumindest in meinem Fall bringt die Selektion nichts, da man bei der Menge an Punkten ohnehin nichts bewerten mehr kann. Das kann man nur, wenn man das gelöschte Ergebnis sieht und tief hineinzoomt.

Was mir noch durch den Kopf geschossen ist: Die Selektionsperformance hat in meinen Augen nur bedingt was mit einem hohen Speicherverbrauch etwas zu tun.
Könnte es sein, dass jeder einzelne Löschvorgang einen Undo-Eintrag erzeugt und damit zum Speicherfresser wird ?

Gruß
Thomas
Reply
#6
(27.11.2012, 06:00)lundefugl Wrote: Zumindest in meinem Fall bringt die Selektion nichts, da man bei der Menge an Punkten ohnehin nichts bewerten mehr kann. Das kann man nur, wenn man das gelöschte Ergebnis sieht und tief hineinzoomt.

Das stimmt. Eigentlich hatte ich das Löschen dafür ausgelegt, eine Route von 300 auf 96 zu bringen. Und dort wollte ich wissen, was denn nun gelöscht wird. Deine Tracks erfordern ein anderes Vorgehen. Vielleicht einen eigenen Dialog? Oder ein anderes Verhalten, wenn mehr als 10000 Punkte in der Positionsliste angezeigt werden?

(27.11.2012, 06:00)lundefugl Wrote: Könnte es sein, dass jeder einzelne Löschvorgang einen Undo-Eintrag erzeugt und damit zum Speicherfresser wird ?

Das könnte sein. Ich habe beim Optimieren der Kartenanzeige gute Erfahrungen mit YourKit gemacht: dort sind Speicherlöcher und Performanceprobleme schnell zu finden.
--
Christian
Reply
#7
Hallo Christian,

(27.11.2012, 18:14)routeconverter Wrote: Deine Tracks erfordern ein anderes Vorgehen. Vielleicht einen eigenen Dialog? Oder ein anderes Verhalten, wenn mehr als 10000 Punkte in der Positionsliste angezeigt werden?

Ich denke, dass bei Langzeitaufzeichnungen mit heutigen Loggern - z.B. über die Ferien - höhere Datenmengen nicht ganz so exotisch sind.

Zwei verschiedene Dialoge (die gelichzeitig angezeigt werden können) würde ich im RC dafür nur ungern sehen. Dann darfst du wieder erklären, wann der eine und wann der andere Dialog verwendet werden soll. Ganz verwirrend wäre es dann auch, wenn die Dialoge noch komplett anders aufgebaut sind.

Was man machen könnte ist, dass der Dialog ab einer bestimmten Punktmenge (z.B. die vorgeschlagenen 10.000 von dir) einfach den Text und das Verhalten bei den Markieren-Buttons ändern. D.h. einfach "Positionen löschen" anzeigen und beim Klick ohne Markierung direkt löschen.

Die beiden unteren Buttons ("Markierung entfernen", "Lösche markierte Positionen") sollten dann natürlich unsichtbar geschaltet werden.

Ob das dann intern 2 getrennte Dialogklassen oder ein Universaldialog ist, spielt keine Rolle - solange der Anwender davon nichts merkt.

Wenns dann ganz universell sein soll, so kann man den Grenzwert über eine versteckte Option konfigurieren, falls es doch irgendwelche Anwender gibt, die einen anderen Grenzwert haben wollen.

Gruß
Thomas
Reply
#8
Ich bin auch einer, der nach seinem Urlaub die aufgezeichneten Tracks mit Routeconverter bearbeitet. Mein Vorgehen dabei ist meist, dass ich den Douglas-Peuker mit einem Grenzwert von 1 Meter durchlaufen lasse und anschließend noch ein paar Punktwolken manuell bearbeite bevor ich alles im gpx exportiere.

Dabei ist mir aufgefallen, dass die erste Version von Routeconverter mit der Performance OK war. Erst später wurde es spürbar schlechter. Die genaue Version weiß ich jetzt nicht mehr. Auch da wurden in der Liste rechts die markierten Eitnräge angezeigt.

Wäre es nicht denkbar, dass man irgendwie die ganze Nachrichtenschleife von markieren, Anzeige aktualisieren, Höhenprofil aktualisieren, Karte aktualisieren für die Zeit der Ermittlung stoppen kann? Das gleiche anschließend beim Löschen.
Reply
#9
Hallo,

(28.11.2012, 09:29)EddiVonDerAlm Wrote: Dabei ist mir aufgefallen, dass die erste Version von Routeconverter mit der Performance OK war. Erst später wurde es spürbar schlechter. Die genaue Version weiß ich jetzt nicht mehr. Auch da wurden in der Liste rechts die markierten Eitnräge angezeigt.

die älteste Version, die ich noch habe ist eine 2.4 vom 21.05.2011. Mit dieser Version habe ich mal eine etwas kleinere Datei ausprobiert. Zur aktuellen Version habe ich dabei keinen Unterschied in der Geschwindigkeit feststellen können - was nicht unbedingt heißt, dass kein Unterschied da ist (evtl. war jetzt die Datei zu klein).

Irgendwie will mir aber die Undo-Funktion nicht aus dem Kopf. Ich weiß zwar nicht, wann das hereingekommen ist, aber evtl. hast du Christian noch irgendwo eine Version davor "herumliegen". Dann könnte man das schnell ausschliessen.

Gruß
Thomas
Reply
#10
Ich verwende dazu eine 1er Version. Da war es noch etwas rudimentärer, für das Ausdünnen aber ausreichend.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)