blackeye501
Geocacher
Nachdem immer wieder die Diskussion um dei Geschwindigkeit des gpx-export aufkommt, hab eich mal wieder einen Blick in den Source-Code geworfen. Dabei sind mir ein paar Punkt aufgefallen, die evtl. die Sache beschleunigen könnten.
Für den gpx-Export wird ja (im Gegensatz zu den anderen Exportern) die Langtextbeschreibung benötigt. Diese wir vom CacheHolderDetail ermittelt.
Und da hätte ich die eine oder andere Idee was zu ändern.
- Der CacheHolderDetail lädt immer alle Informationen in die entsprechenden Variablen, obwohl wie beim gpx-Export nur Langtext und Hint benötigt werden.
Wäre es nicht sinnvoll dem CacheHolderDetail mitzugeben welche Informationen benötigt werden ?
- Es wird bei CacheHolderDetail immer zuerst die gesamte xml-Datei in eine Variable geladen, und diese Variable dann für jedes CacheDetail einmal dem Extractor übergeben, der immer vom Anfang bis zum entsprechendem TAG die Varable durchsucht und das Ergebniss anschliesend in die gewünscht Variable schreibt. Ich denke, das dabei mehr Speicher als nötig verwendet wird.
Könnte man nicht die Datei Zeichen für Zeichen lesen und dann wenn das gewünschte Tag auftaucht die entsprechende Variable damit befüllen.
- Kombiniert man jetzt beide Schritte kann evtl. schon nach einlesen der ersten paar Zeilen (wenn die gewünschten TAGs sachon dabei waren) die Datei wieder geschlossen werden.
Ich könnte mir vorstellen, dass bei Umsetzung der Punkt wesentlich weniger Speicher benötigt wird und die Lesezeiten vom Datenträger sinken (da nicht immer die gesamte Datei benötigt wird)
Die Speichernutzung und Freigabe scheint in Java ja ein entscheidender Punkt bei der Geschwindigkeit zu sein. Die garbage collection verbraucht ja schon eine nicht unerhebliche Zeit. Evtl. liegt darin auch der Geschwindigkeitsunterschied zwischen SunJAVA und Ewe. SunJAVA belegt bei der Ausführung vom Cachewolf schon mal schnell 100MB Speicher und mehr. Ewe begnügt sich statt dessen mit 10-15 MB.
Für den gpx-Export wird ja (im Gegensatz zu den anderen Exportern) die Langtextbeschreibung benötigt. Diese wir vom CacheHolderDetail ermittelt.
Und da hätte ich die eine oder andere Idee was zu ändern.
- Der CacheHolderDetail lädt immer alle Informationen in die entsprechenden Variablen, obwohl wie beim gpx-Export nur Langtext und Hint benötigt werden.
Wäre es nicht sinnvoll dem CacheHolderDetail mitzugeben welche Informationen benötigt werden ?
- Es wird bei CacheHolderDetail immer zuerst die gesamte xml-Datei in eine Variable geladen, und diese Variable dann für jedes CacheDetail einmal dem Extractor übergeben, der immer vom Anfang bis zum entsprechendem TAG die Varable durchsucht und das Ergebniss anschliesend in die gewünscht Variable schreibt. Ich denke, das dabei mehr Speicher als nötig verwendet wird.
Könnte man nicht die Datei Zeichen für Zeichen lesen und dann wenn das gewünschte Tag auftaucht die entsprechende Variable damit befüllen.
- Kombiniert man jetzt beide Schritte kann evtl. schon nach einlesen der ersten paar Zeilen (wenn die gewünschten TAGs sachon dabei waren) die Datei wieder geschlossen werden.
Ich könnte mir vorstellen, dass bei Umsetzung der Punkt wesentlich weniger Speicher benötigt wird und die Lesezeiten vom Datenträger sinken (da nicht immer die gesamte Datei benötigt wird)
Die Speichernutzung und Freigabe scheint in Java ja ein entscheidender Punkt bei der Geschwindigkeit zu sein. Die garbage collection verbraucht ja schon eine nicht unerhebliche Zeit. Evtl. liegt darin auch der Geschwindigkeitsunterschied zwischen SunJAVA und Ewe. SunJAVA belegt bei der Ausführung vom Cachewolf schon mal schnell 100MB Speicher und mehr. Ewe begnügt sich statt dessen mit 10-15 MB.
