ich habe eine große Datei, c.a. 3 GB, und möchte ich sie jetzt in einem Zip File einpacken um Platz zu sparen (die Datei ist jetzt c.a. 800MB), und dann lese ich das Inhalt direkt aus den Zip File.
Aber irgendwie finde ich das Einlesen von den Zip File ist sehr langsam, besonders wenn man "skip( )" eine große Schritt. Ist das normal??? oder gibt es bessere Methode???
Natürlich ist das normal. Die Datei muss ja erst einmal entpackt werden bevor die Daten gelesen werden können. Du musst halt entscheiden was dir wichtiger ist - Speicherplatz sparen oder schneller lesen.
Natürlich ist das normal. Die Datei muss ja erst einmal entpackt werden bevor die Daten gelesen werden können. Du musst halt entscheiden was dir wichtiger ist - Speicherplatz sparen oder schneller lesen.
Wenn die Bottlenecks tatsächlich wirklich lange Skip-Schritte sind (sowas wie: skip 200MB in a row), dann müsste's doch dafür eine Lösung geben. Man könnte beispielsweise die unkomprimierte Datei in Brocken von 5MB zerhacken und die Brocken als einzelne ZIP-Entries im ZIP-Container speichern. Dann könnte man fast in Nullzeit den richtigen Brocken identifizieren und anspringen können, ohne alle vorangegangenen Entries zu inflaten, und müsste dann nur innerhalb des richtigen Entries inflaten.
Die ZipInputStream-Implementierung (wie auch die GZIPInputStream-Implementierung) realisieren [c]skip()[/c] nur über [c]read()[/c]. Ich hatte eigentlich gehofft per kurzer Netzrecherche Kompressionswerkzeuge zu finden die Bereiche einer komprimierten Datei dekomprimieren können, indem sie ein Lexikon auslesen und dann nur diejenigen Blöcke dekomprimieren in denen sich der Dateibereich befindet. Aber ich fand nichts; was gut und gern auch an fehlender Kenntnis und damit suboptimaler Suchwortwahl liegen kann.
Aber der oben geschilderte Weg sollte bei "Riesensprüngen" die Performance immens steigern. Oder hab ich da einen Denkfehler?
Wenn die Bottlenecks tatsächlich wirklich lange Skip-Schritte sind (sowas wie: skip 200MB in a row), dann müsste's doch dafür eine Lösung geben. Man könnte beispielsweise die unkomprimierte Datei in Brocken von 5MB zerhacken und die Brocken als einzelne ZIP-Entries im ZIP-Container speichern. Dann könnte man fast in Nullzeit den richtigen Brocken identifizieren und anspringen können, ohne alle vorangegangenen Entries zu inflaten, und müsste dann nur innerhalb des richtigen Entries inflaten.
Die ZipInputStream-Implementierung (wie auch die GZIPInputStream-Implementierung) realisieren [c]skip()[/c] nur über [c]read()[/c]. Ich hatte eigentlich gehofft per kurzer Netzrecherche Kompressionswerkzeuge zu finden die Bereiche einer komprimierten Datei dekomprimieren können, indem sie ein Lexikon auslesen und dann nur diejenigen Blöcke dekomprimieren in denen sich der Dateibereich befindet. Aber ich fand nichts; was gut und gern auch an fehlender Kenntnis und damit suboptimaler Suchwortwahl liegen kann.
Aber der oben geschilderte Weg sollte bei "Riesensprüngen" die Performance immens steigern. Oder hab ich da einen Denkfehler?
