... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
RC wird immer langsamer
#11
(14.08.2013, 15:44)lupus52 Wrote: Bei mir ist es egal welche Karte ich im RC nehme. Habe schon alle verfügbaren Karten probiert und kann keine Geschwindigkeitsunterschiede feststellen.

Ich wollte eher darauf hinaus, ob die anderen Werkzeuge auch Google Maps oder OpenStreetmap einbetten oder das Zeichnen der Karte selbst übernehmen.

(14.08.2013, 15:44)lupus52 Wrote: Z.B. http://www.gpstrackeditor.com ist "sauschnell" <g> - keine Ahnung mit was das arbeitet. ZUmindest spielt da die gewählte Karte keine Rolle.

Die Screenshots enthalten nur Linien, das läßt sich natürlich viel schneller malen als über Google Maps, DJNativeSwing, SWT, IE
--
Christian
Reply
#12
(14.08.2013, 15:54)routeconverter Wrote:
(14.08.2013, 15:44)lupus52 Wrote: Bei mir ist es egal welche Karte ich im RC nehme. Habe schon alle verfügbaren Karten probiert und kann keine Geschwindigkeitsunterschiede feststellen.

Ich wollte eher darauf hinaus, ob die anderen Werkzeuge auch Google Maps oder OpenStreetmap einbetten oder das Zeichnen der Karte selbst übernehmen.
Fast alle getesteten Tools nehmen entweder GoogleMaps oder OSM-Karten. Zumindest soweit ich das gesehen habe

Quote:
(14.08.2013, 15:44)lupus52 Wrote: Z.B. http://www.gpstrackeditor.com ist "sauschnell" <g> - keine Ahnung mit was das arbeitet. ZUmindest spielt da die gewählte Karte keine Rolle.

Die Screenshots enthalten nur Linien, das läßt sich natürlich viel schneller malen als über Google Maps, DJNativeSwing, SWT, IE

Also ich habe da komplette auswählbare Karten. Und zwar die bekannten wie Mapnik, Cycle u.s.w.
Reply
#13
Zwischenbericht:

Gerade ist mir beim Arbeiten mit RC wieder mal aufgefallen, daß er extrem langsam wurde. Im Prozessexplorer fand ich dann 80% Auslastung durch Java. Permanent +/- 2 bis 3 Prozent. Bei weiterer Suche entdeckte ich, daß 2 Versionen von JAVAW.EXE liefen. Und unter einer davon ein JAVA.EXE. Die beiden JAVAW waren in unterschiedlichen Verzeichnissen.

Deshalb ging ich davon aus, daß eine ein Relikt von früher ist. Ich habe dann JAVA komplett deinstalliert und die Unmenge verbliebener Reste von Hand gelöscht. Eine miserable Deinstallationsroutine hat dieses JAVA! Ich habe dann die JAVA 7 neu downgeloadet und installiert. Wieder wird JAVA 2 mal installiert. Einmal unter \windows\system32 und einmal unter \Programme\Jave. Letzteres wird von RC benutzt. Und jAnrufmonitor nimmt das unter \windows\system32.

Ich habe leider versäumt rauszubekommen welche der beiden laufenden JAVAs die hohe Auslastung erzeugt hat.

Aber der Fall tritt garantiert wieder auf.
Reply
#14
(15.08.2013, 16:40)lupus52 Wrote: Gerade ist mir beim Arbeiten mit RC wieder mal aufgefallen, daß er extrem langsam wurde. Im Prozessexplorer fand ich dann 80% Auslastung durch Java. Permanent +/- 2 bis 3 Prozent. Bei weiterer Suche entdeckte ich, daß 2 Versionen von JAVAW.EXE liefen. Und unter einer davon ein JAVA.EXE. Die beiden JAVAW waren in unterschiedlichen Verzeichnissen.

Es ist normal, daß es 2x javaw.exe im System gibt (s.u.) und daß, wenn RouteConverter läuft, 2x javaw.exe in der Prozeßliste steht.

(15.08.2013, 16:40)lupus52 Wrote: Deshalb ging ich davon aus, daß eine ein Relikt von früher ist. Ich habe dann JAVA komplett deinstalliert und die Unmenge verbliebener Reste von Hand gelöscht. Eine miserable Deinstallationsroutine hat dieses JAVA! Ich habe dann die JAVA 7 neu downgeloadet und installiert. Wieder wird JAVA 2 mal installiert. Einmal unter \windows\system32 und einmal unter \Programme\Jave. Letzteres wird von RC benutzt.

Das ist normal. Das unter \windows\system32 liegende java.exe/javaw.exe ist ein Stummel, der in der Registry nach der zu startenden Java-Version unter Programme sucht und startet.

(15.08.2013, 16:40)lupus52 Wrote: Ich habe leider versäumt rauszubekommen welche der beiden laufenden JAVAs die hohe Auslastung erzeugt hat.

Das wäre interessant. Ich vermute, es ist das von \windows\system32 mit dem der eingebettete IE gestartet wird.
--
Christian
Reply
#15
Ich habe mal den Profiler angeworfen, um zu schauen, wie lange das Löschen von 5 Positionen aus einem Track mit 100000 Positionen benötigt.
Wie man aus dem angehängten Call Trace sehen kann, sind das 140ms auf meinem 3 Jahre alten Notebook mit Java 1.6.0_51, IE 10.0.9200.16660 für das Neuzeichnen der Tabelle, Aktualisierung der Tracklänge, Neuzeichnen des Höhenprofils. Die Aktualisierung der Karte findet asynchron im IE statt und ist deshalb nicht enthalten.
Auf die von lupus52 gemessenen 5 Sekunden komme ich nicht ansatzweise. Daher die Frage:
  • wie sieht die Hardware aus?
  • wieviel Prozessor steckt im Rechner?
  • wieviel Speicher hat der Rechner?
  • welche IE Version ist im Einsatz?


Attached Files Thumbnail(s)
   
--
Christian
Reply
#16
(12.08.2013, 16:34)lupus52 Wrote: Ich vermute mal, daß das ganze Problem durch JAVA verursacht wird. Auf meinem Lappi habe ich eine andere Anwendungt, die ebenfalls JAVA intensiv nutzt. Auch die wird immer langsamer. Bis hin zu kompletten minutenlangen Hängern.
Dann solltest du deine Java-Installation(en) mal mit allen Trümmern komplett entsorgen. Händisch ist das kaum zu schaffen, dafür gibt es ein spezialisiertes Tool, das Oracle eigentlich gleich mitliefern sollte: JavaRa.. Nachdem du damit alles entsorgt hast, was irgendwie mit Java zu tun hat, starte den Rechner neu und installiere dann genau eine und nur eine Java-Version neu, entweder Java 6 Update 45 oder Java 7 Update 25, und mach das mit den Offline-Versionen von der Java-Webseite.

Wenn das nicht hilft, solltest du vielleicht in Betracht ziehen, den Rechner neu aufzusetzen, dabei wird dann auch der ganze Müll von früheren Testinstallationen und sonstigen Spielereien entsorgt, die den Rechner ausbremsen. Man kann es vorher noch mal im Guten versuchen, es gibt halbwegs harmlose Putzmittel wie den CCleaner, etwas gröbere wie z.B. den RevoUninstaller oder sehr scharfe wie RegSeeker, letzterer ist nur was für Leute, die genau wissen, was sie da tun.

(12.08.2013, 16:34)lupus52 Wrote: Ich habe gerade eben mal "GPS-Track-Analyse.NET 6" ausprobiert und getestet. Abgesehen von der etwas komischen Bedienung ist das blitzschnell im Gegensatz zu RC. Ich werde wohl oder übel teilweise oder ganz umsteigen.
GTA hat erstklassige Analyse-Funktionen, den Rest können andere auch und/oder besser. Ich hab's wieder gekickt.

(12.08.2013, 16:34)lupus52 Wrote: Ich arbeite privat noch mit XP und das wird so lange so bleiben, wie meine Hardware das mitmacht.
Bei mir läuft RouteConverter in der Vorabversion auf einem älteren Panasonic CF-52 mit 1,6GHz Dual Core, 4GB Speicher, XP SP3, IE8 und Java 7u25 problemlos und für meine Anwendungen schnell genug.

Dein Urteil über W8 kann ich nachvollziehen, bei W7 bin ich anderer Meinung. Mein Firmenrechner und mein Tablett laufen mit W7 und das sehr gut und zuverlässig, und wenn du ein mit kommerzieller Software einsetzbares 64bit-System brauchst, geht eh kein Weg dran vorbei. Das Sicherheitsproblem befindet sich in der Regel zwischen Tastatur und Rückenlehne.
Grüße
Hans

Reply
#17
(16.08.2013, 20:03)nordlicht Wrote:
(12.08.2013, 16:34)lupus52 Wrote: Ich vermute mal, daß das ganze Problem durch JAVA verursacht wird. Auf meinem Lappi habe ich eine andere Anwendungt, die ebenfalls JAVA intensiv nutzt. Auch die wird immer langsamer. Bis hin zu kompletten minutenlangen Hängern.
Dann solltest du deine Java-Installation(en) mal mit allen Trümmern komplett entsorgen. Händisch ist das kaum zu schaffen, dafür gibt es ein spezialisiertes Tool, das Oracle eigentlich gleich mitliefern sollte: JavaRa.. Nachdem du damit alles entsorgt hast, was irgendwie mit Java zu tun hat, starte den Rechner neu und installiere dann genau eine und nur eine Java-Version neu, entweder Java 6 Update 45 oder Java 7 Update 25, und mach das mit den Offline-Versionen von der Java-Webseite.

Wenn das nicht hilft, solltest du vielleicht in Betracht ziehen, den Rechner neu aufzusetzen, dabei wird dann auch der ganze Müll von früheren Testinstallationen und sonstigen Spielereien entsorgt, die den Rechner ausbremsen. Man kann es vorher noch mal im Guten versuchen, es gibt halbwegs harmlose Putzmittel wie den CCleaner, etwas gröbere wie z.B. den RevoUninstaller oder sehr scharfe wie RegSeeker, letzterer ist nur was für Leute, die genau wissen, was sie da tun.
Danke - der Hauptrechner wurde erst neu aufgesetzt. Und Java vor ein paar Tagen komplett entsorgt und neu installiert. Daran liegt es nicht, dass die aktuelle Version mit altem Schrott zugemüllt ist. Dies sporadische Langsamkeit begleitet mich nun schon mehrere Jahre. Ich kann damit leben. Auch wenn es nervt. Mein Gefühl ist nur, dass es immer schlimmer wird mit jedem Update. Aber wie gesagt, das ist Gefühl. Tatsache ist auf jeden Fall, dass manche DELs bis zu 5 Sekunden brauchen bis das Bild neu aufgebaut ist bzw. das geänderte Trackstück neu gezeichnet ist. Bei anderen dann geht es wieder blitzschnell. Ich habe noch kein System entdecken können. Es ist auf jeden Fall JAVA selbst, was da bremst. Laut Prozessexplorer springt die CPU-Last durch JAVA auf 100% und bleibt diese Sekundenzahl so hoch.
Reply
#18
(17.08.2013, 16:15)lupus52 Wrote: Laut Prozessexplorer springt die CPU-Last durch JAVA auf 100% und bleibt diese Sekundenzahl so hoch.

Das klingt nach einer Full Garbage Collection. Falls Du eine 32-Bit RouteConverter-Version verwendest, dann ist die auf ein Maximum von 512 MByte Heap konfiguriert, bei 64-Bit ist es das Doppelte. Das könnte zu längeren Wartezeiten führen, wenn
  1. es trotz Profiling doch noch Memory Leaks in RouteConverter gibt
  2. Du wirklich _sehr_ lang am Stück mit RouteConverter arbeitest
  3. Dein Rechner 2 GByte Speicher oder weniger hat und swappt
  4. Dein Rechner 4 GByte Speicher hat, aber durch viele Programme kaum etwas frei ist und er swappt
  5. Dein XP eine Woche läuft und der Filecache den größten Teil des Arbeitsspeichers belegt und so zu Swapping führt (bekannter Bug)
--
Christian
Reply
#19
(18.08.2013, 20:46)routeconverter Wrote:
(17.08.2013, 16:15)lupus52 Wrote: Laut Prozessexplorer springt die CPU-Last durch JAVA auf 100% und bleibt diese Sekundenzahl so hoch.

Das klingt nach einer Full Garbage Collection. Falls Du eine 32-Bit RouteConverter-Version verwendest,
ja

Quote:dann ist die auf ein Maximum von 512 MByte Heap konfiguriert, bei 64-Bit ist es das Doppelte. Das könnte zu längeren Wartezeiten führen, wenn

[*]es trotz Profiling doch noch Memory Leaks in RouteConverter gibt
[*]Du wirklich _sehr_ lang am Stück mit RouteConverter arbeitest
was ist sehr lang? Es ist schon mal Stunden. Aber das Problem beginnt i.d.R. sehr schnell. Also schon nach Minuten.

Quote:[*]Dein Rechner 2 GByte Speicher oder weniger hat und swappt
Ich habe 2 GB. Und eigentlich immer genug davon frei bzw. verfügbar laut Systeminfo.

Quote:[*]Dein Rechner 4 GByte Speicher hat, aber durch viele Programme kaum etwas frei ist und er swappt
Viele Programme sind schon grundsätzlich immer aktiv. Zumindest in der Taskleiste. Das gibt aber mit keinem anderen Programm Probleme.

Quote:[*]Dein XP eine Woche läuft und der Filecache den größten Teil des Arbeitsspeichers belegt und so zu Swapping führt (bekannter Bug)
Mein Hauptrechner läuft nie durch. Wird also jeden Tag neu gestartet. Allerdings arbeite ich mit sehr vielen Programmen im Wechsel.

Vielleicht hilft es ja, wenn ich mal kurz noch schildere, was ich da konkret mache. Ich habe z.B. einen GPX-File mit 12000 Einträgen. So wie gestern. Meine Trackingsoftware ist auf 2 Sekunden eingestellt. Leider hat die Software keine Intelligenz wie mein Garmin, welches sein Intervall selbst anpasst was es zu speichern hat.

Zuerst lasse ich dann de Track automatisch bereinigen. D.h. unnötige Punkte unter 5 Meter Abstand zum Vorgänger werden gelöscht.

Dann kommt die Handarbeit. Da die Touren später mal als Vorlage zum Nachfahren dienen sollen, werden nun alles logisch unnötigen Punkte gelöscht. Z.B. Punkte auf einer langen leicht geschlängelten Geraden wo es gar keine Abbiegemöglichkeitne gibt. Dann kommen die ganzen Korrekturen mit weiterem Bereinigen. Das alles wird meistens in fast größter Vergrößerung gemacht. Dadurch wird die Karte bei fast jeden DEL oder Verschieben nachgeführt. Und spätestens dann geht es los mit langsam. Man hat das Gefühl, dass jede (Teil-)Kachel neu aus dem Netz geladen wird. Beim schnellen Löschen mehrerer Punkte gibt das dann auch oft auch ein wildes Gezappel. D.h. die Karte wird angefangen zu verschieben, kommt wieder zurück, wird wieder verschoben, geht dann woanders hin und wieder zurück. Da gehen wohl alle Verschiebebefehle in ein Fifo und werden stur und unnötig abgearbeitet. Auch wenn die nächste Verschiebung in eine ganz andere Richtung geht wird die vorige Verschiebung erst (langsam) fertig gezeichnet.
Reply
#20
(19.08.2013, 07:56)lupus52 Wrote: Vielleicht hilft es ja, wenn ich mal kurz noch schildere, was ich da konkret mache.

Das hilft sehr.

(19.08.2013, 07:56)lupus52 Wrote: Ich habe z.B. einen GPX-File mit 12000 Einträgen. [..]
Zuerst lasse ich dann de Track automatisch bereinigen. [..]
Dann kommt die Handarbeit. [..]
Das alles wird meistens in fast größter Vergrößerung gemacht. Dadurch wird die Karte bei fast jeden DEL oder Verschieben nachgeführt. Und spätestens dann geht es los mit langsam. Man hat das Gefühl, dass jede (Teil-)Kachel neu aus dem Netz geladen wird.

Das ist sehr wahrscheinlich, da auf den größeren Detailstufen die Kacheln selten schon verwendet wurden und schon gecacht sind. Es sind einfach zu viele.

Andererseits passiert das asynchron in einem weiteren Prozeß und macht RouteConverter nur dann langsamer, wenn Dein Rechner gut ausgelastet ist.

(19.08.2013, 07:56)lupus52 Wrote: Beim schnellen Löschen mehrerer Punkte gibt das dann auch oft auch ein wildes Gezappel. D.h. die Karte wird angefangen zu verschieben, kommt wieder zurück, wird wieder verschoben, geht dann woanders hin und wieder zurück. Da gehen wohl alle Verschiebebefehle in ein Fifo und werden stur und unnötig abgearbeitet.

Alle Verschiebebefehle (technisch panTo() damit die aktuell markierte Position immer im Kartenausschnitt liegt) werden in der Tat in der Reihenfolge der Änderungen an der Markierung ausgeführt. Einem Rechner "unnötig" aus Kriterien beibringen, um Arbeit zu vermeiden, ist nämlich gar nicht so einfach. Wer programmiert, weiß, wie schwer es ist "schlau" zu optimieren und dabei keine Fehler zu machen: man weiß halt nie, was der Nutzer als nächstes gerade vorhat und wann er es tut. Hält man die Reaktion darauf zu lange zurück, um unnötige Operationen zu vermeiden, wirkt das Programm schnell träge und scheint nicht zu tun, was man erwartet.

(19.08.2013, 07:56)lupus52 Wrote: Auch wenn die nächste Verschiebung in eine ganz andere Richtung geht wird die vorige Verschiebung erst (langsam) fertig gezeichnet.

Das scheint darauf hinzudeuten, daß Dein Setup (Rechner, Internetverbindung, IE) recht langsam ist und/oder wenig Ressourcen bereitstellen kann. Mit einem aktuellen Setup nimmt man Verschiebungen, Kacheln laden etc. gar nicht wahr.

Ich habe mal versucht, genau so zu arbeiten, wie Du beschrieben hast und ein bißchen "unnötige" Arbeit zu vermeiden. Bitte lade dazu die neueste Vorabversion herunter und berichte, wie sich das anfühlt.
--
Christian
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)