Java: Parsen großer Dateien

Re(14): Java: Parsen großer Dateien

Nagelfar — Fri, 24 Nov 2006 10:17:11 GMT

Theorie vs. Praxis

Wie so oft

aber ich kenn das GHF halt auch als Ideenquelle

Jap,ich bevorzug aber mein ICQ, mindestens 10 gut Ausgebildete Informatiker fast 24h auf Abruf bereit *g*

Re(4): nun ... doch...

m3t4tr0n — Fri, 24 Nov 2006 10:15:43 GMT

Ist eine satte Mischung aus Perl und C, soviel ich bis jetzt gesehen habe.

Re(13): Java: Parsen großer Dateien

m3t4tr0n — Fri, 24 Nov 2006 10:12:41 GMT

>Allerdings bezweifel ich, dass das an einen Kunden rausgehen soll

Nein, geht nicht an einen Kunden (ich glaub nicht, daß das wer haben will hehe). Die Entwicklungszeit beträgt rund 6 Wochen - das ist schon recht wenig, so daß ich auch (und grad weils nicht für Kunden ist ) mit durchschnittlich guten Ergebnissen zufrieden bin.

>sonst würds nicht ein Anfänger (net bös gmeint)

Jedenfalls Anfänger, wenns um solche Datenmassen geht. Auf dem Papier sieht nach der Modellierung alles so schön aus - Theorie vs. Praxis.

>allein entwickeln müssen.

Bin in einem 3er Team in einem 12er Team. Nicht, daß ich nicht mit den Kollegen drüber diskutiert hätte, aber ich kenn das GHF halt auch als Ideenquelle.

Re: Java: Parsen großer Dateien

cyran — Fri, 24 Nov 2006 09:56:03 GMT

Nachdem es hier schon mal kurz angeklungen ist, das Ganze in einer DB zu speichern.

Was waere den von JavaDB zu halten in diesem Fall.
http://developers.sun.com/prodtech/javadb/

Vielleicht kann einer von den Java-Kennern etwas dazu sagen ?
Scheint ja vom Platz recht klein zu sein.

Re(11): Java: Parsen großer Dateien

thE — Fri, 24 Nov 2006 09:44:38 GMT

Toll

Gib das mal nem DAU Kunden.. oder Leuten die nicht mal helloworld Programme starten können

Und man glaubt gar nicht wieviele Leute es noch gibt die mit .jar sowieso nix anfangen können

Wenns keine EXE ist gehts auch net ausführen...

Re(9): Java: Parsen großer Dateien

thE — Fri, 24 Nov 2006 09:37:03 GMT

Und wie setzt du den Wert auf max. wenn du vorher nicht weißt wieviel MB RAM der hat?!

Re(3): Java: Parsen großer Dateien

thE — Fri, 24 Nov 2006 09:21:00 GMT

Naja mach halt ne Dll oder so Datei drauß

Re(11): Java: Parsen großer Dateien

Linux_Sucks — Fri, 24 Nov 2006 09:09:27 GMT

Nun ja...

AFAIK liegts an der VM... Du kannst aber was "perverses" bauen:

1.) 2 getrennte VMs starten
2.) 2 Apps in die 2 VMs
3.) die Apps kommunizieren untereinander und parsen gemeinsam... So daß jede VM mit 2GB auskommt.... Also quasi ein Cluster auf demselben Rechner.

Das klingt mal blödsinnig, es liegt aber einfach daran, daß du auch auf einem System mit 20GB Ram nur so rund 2-3GB in eine VM reinbekommst... Drum mehr VMs starten

Wenn wir schon oT sind:

Linux_Sucks — Fri, 24 Nov 2006 09:06:24 GMT

Wird jedenfalls ein spannender Umstieg für Javianer....

32bit waren beim Beginn vom Java eh super... Nur sollten neue JavaVMs schön langsam echt 64bit schaffen.
Ich bin ja gespannt, wie das gelöst wird - oder wie es gelöst wurde, so ich es verpennt habe.

Denn daß eine 32bit-VM via Serialisierung seine Klassen einer 64bit-VM liefert, kann man sich ja noch "leichter" vorstellen... Andersrum ists sicher doppelt so schwer. Wird sicher eine Herausforderung für Sun - und die Entwickler, aber sicher auch spannend und lehrreich... *freu*

Was sagst eigentlich zur 6er-VM ? Also zum RC.... Schon eingelesen, was kommt ?
Zu meiner Schande muß ich gestehen, daß ich fix nur auf 1.4 baue... Portabel und so... Scheint so, als obs nun einiges zum Nachstrabern gibt .

Angeblich sind ja generics nun fix drinnen - oder kam das schon mit der 5er ???

Re(10): Java: Parsen großer Dateien

m3t4tr0n — Fri, 24 Nov 2006 09:05:28 GMT

>AFAIK schaffst nicht einmal 3GB

Mehr als 2600M konnte ich der VM nicht mitgeben, obwohl ich 4GB zur Verfügung habe.

Ich hoffe eher, daß der neue Ansatz (http://forum.geizhals.at/t459858,3793571.html#3793571 ) fruchten wird. Parsen zweier langer Char[] (geht in wenigen Sekunden und braucht kaum Speicher) und gegen Ende des Programms nochmal die Indizes dazu besorgen... bis dahin kann ich eventuell auch die Char[] Größe reduzieren.

Re(10): Java: Parsen großer Dateien

m3t4tr0n — Fri, 24 Nov 2006 09:05:28 GMT

>AFAIK schaffst nicht einmal 3GB

Mehr als 2700M konnte ich der VM nicht mitgeben, obwohl ich 4GB zur Verfügung habe.

Ich hoffe eher, daß der neue Ansatz (http://forum.geizhals.at/t459858,3793571.html#3793571 ) fruchten wird. Parsen zweier langer Char[] (geht in wenigen Sekunden und braucht kaum Speicher) und gegen Ende des Programms nochmal die Indizes dazu besorgen... bis dahin kann ich eventuell auch die Char[] Größe reduzieren.

Re(15): Java: Parsen großer Dateien

Linux_Sucks — Fri, 24 Nov 2006 09:00:30 GMT

>Keine Ahnung ob es da schon was gibt. 64bit OS sind afaik nicht so verbreitet.
Thema Numbercrunching, große Daten, ... Kenne ich echt kein 32bit-OS im Produktiveinsatz....
Wir verwenden da rein Unixoide... AIX, Linux, Solaris, ... sogar zOS ist ja inzwischen Thema Daten 64bittig...

64bitOS sind IMHO, AFAIK, ... absoluter Standard - ausgenommen Homeuser. Als Daumenregel würde ich mal annehmen, daß ab 2-3GB Ram ein 64bit-OS absolut sinnvoll ist... und sei es nur um sinnvoll swappen zu können . Aber ist ein bißchen oT... Er hat jedenfalls eines.

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Fri, 24 Nov 2006 08:59:49 GMT

>Musst du echt den ganzen Datenbestand im Speicher haben?
>Wie willst danach drauf zugreifen?

Ja, aber wie ich mittlerweile festgestellt habe, nicht die komplette Tupelinformation.

Ersatzlösung ist es jetzt, die einzelnen Tupelinformationen in getrennten Parsedurchgängen zu besorgen, wenn sie benötigt werden - die Laufzeit leidet zwar ein wenig darunter, aber die ist vorerst auch nicht so wichtig.

>Noch was: Wieviele Datensätze (Tupel) sind das?

Zwischen 150 Mio. und 20 Mio.

Re(2): nun ... doch...

Linux_Sucks — Fri, 24 Nov 2006 08:57:08 GMT

Wenn die Vorgabe Java ist, ist es eh außer Diskussion... Für mich wirkte es so, als ob es keine Vorgabe gibt und er es auch in C lösen könnte...

Welchen Flamewar hab ich übrigens verpaßt ?

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Fri, 24 Nov 2006 08:56:50 GMT

>Schon mal überlegt das ganze in C zu schreiben?

Hab Java als Projektvorgabe... man würde mich würgen, würde ich jetzt C in den Raum werfen (auch wenn alle ähnlichen Projekte bisher in C geschrieben worden sind...).

Re: nun ... doch...

Nagelfar — Fri, 24 Nov 2006 08:53:45 GMT

Sry, nach dem Flamewar gestern hab ich entschieden, mich hier nicht mehr auf Diskussionen einzulassen Seine Anforderung/Vorgabe scheint Java zu sein, deshalb sind Diskussionen über C/C++ für micht nicht zielführend.

Re(13): Java: Parsen großer Dateien

Linux_Sucks — Fri, 24 Nov 2006 08:51:50 GMT

4 Gig VIRTUAL Memory sind nicht so unüblich... Und wir reden ja von seinem speziellen Fall... Und nur um den geht's

Ich habe keine Ahnung, ob es inzwischen eine JavaVM gibt, in der man die Heapsize auf 64bit-Werte setzen kann, also zB 10GB (denn das hätte ihm ja sofort geholfen), vermute allerdings nein... Denn ab dann stelle ich mir Serialisierung von Objekten stressiger vor (wenn die serialisierten Objekte einer 32bit-VM unterschiedliche Referenzgrößen haben als bei einer 64bit-VM).

nun ... doch...

Linux_Sucks — Fri, 24 Nov 2006 08:48:29 GMT

>Eben und net schon wieder Java ist langsam, gell

Bei reinem number-Crunching muß es langsam sein (ne VM hat ja so einiges zu tun ).
Ich bin bei Dir, daß in der Regel Programme eh auf Eingaben warten, mir ist auch klar, daß _angeblich_ Javadatenbanken wie Derby eine recht gute Performance haben...

Trotz allem würde ich bei CPU-Bound programmen auch C bevorzugen. Wobei es AFAIK ja auch einen Compiler Java-NativeCode gibt, der net so schlecht sein soll - dann wäre es wieder ok.

Ich würde also behaupten, daß das Vorurteil "Java ist grundsätzlich langsam" falsch ist - genauso aber auch das Vorurteil "Java ist eh immer gleich schnell wie C, ..."

Ich vermute, daß sein Proggy, daß mehrfach 70 Mio Tupel aggregiert/analysiert/... durchaus CPU-Bound sein könnte... Also sowohl aus dem Eck als auch wegen der Memory-Limits wäre Java vermutlich in diesem Fall nicht meine erste Wahl.

Re(11): Java: Parsen großer Dateien

Linux_Sucks — Fri, 24 Nov 2006 08:43:03 GMT

Nun ja... Er hatte in seinem Eröffnungspost geschrieben, daß er auf einem 64bit-OS entwickelt...
Damit kann man es - notfalls - mit SWAP lösen. Ist zwar nicht die super-Performante Lösung, aber besser die zweitbeste Lösung jetzt als die beste nie (klingt auch nach einem Java-kompatiblen Motto )

Re(9): Java: Parsen großer Dateien

Linux_Sucks — Fri, 24 Nov 2006 08:39:56 GMT

Ahem... Nein .

Zumindest AFAIK bei Java... Denn du kommst ja auch bei einem 64bit-OS net über die 4GB-Grenze drüber (AFAIK schaffst nicht einmal 3GB).

Bei C wäre es relativ wurscht - 64bit-Memoryzugriffe sind da Streßfrei.

Re(7): Java: Parsen großer Dateien

thE — Fri, 24 Nov 2006 08:07:57 GMT

Naja, er hatte ja schon mal nen memory out Error, wenn er es mit weniger xmx startet!

Von daher würde ich den C weg schon mal überlegen!

Obs jetzt wirklich schneller ist, sei mal dahingestellt!

Vorteil ist jener, das C Programme ja nicht mit irgendeinem Speicherlimit (außer dem Speicher selbst) gestartet werden!

Re(5): Java: Parsen großer Dateien

thE — Fri, 24 Nov 2006 07:39:06 GMT

Ich bin Java Programmierer ^^

Und würde sowas trotzdem mit C machen (okay ich bin auch C/C++ Entwickler )

Re(3): Java: Parsen großer Dateien

thE — Fri, 24 Nov 2006 07:16:27 GMT

Den java.lang.memory Error hätte er nicht mehr

Achja und schneller wirds auch sein!

Re(2): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 21:18:57 GMT

http://forum.geizhals.at/t459858,3792417.html#3792417

Re: Java: Parsen großer Dateien

Robert Craven — Thu, 23 Nov 2006 21:00:48 GMT

Was soll dann nachher mit dem Tupel[] passieren? Musst du echt den ganzen Datenbestand im Speicher haben? Wie willst danach drauf zugreifen? Hast eine Vorgabe bezüglich Laufzeit?

Re: Java: Parsen großer Dateien

Robert Craven — Thu, 23 Nov 2006 21:00:48 GMT

Was soll dann nachher mit dem Tupel[] passieren? Musst du echt den ganzen Datenbestand im Speicher haben? Wie willst danach drauf zugreifen? Hast eine Vorgabe bezüglich Laufzeit?

Noch was: Wieviele Datensätze (Tupel) sind das?

Re: Java: Parsen großer Dateien

thE — Thu, 23 Nov 2006 20:49:32 GMT

Nur so ne Frage, was machst du mit den Daten dann?

Schon mal überlegt das ganze in C zu schreiben?

Einhängen in eine Liste (zB eine von der STL) und file einlesen ist in c auch net so schwer!

Re(10): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 17:20:26 GMT

>Ich würde sagen - probier mal die Lösung ohne ArrayList,
>wirklich nur ein Array fester Größe und gut ists.

Hat leider nichts gebracht. Ich hab inzwischen den Typen "Tupel" auf zwei byte und keine Integer beschränkt - siehe da, es läuft annehmbar mit ArrayList/Vector oder Array fester länge. Mein Ziel scheint es also wirklich zu sein, die Anzahl an Objekten zu reduzieren.

Wenn das reine Parsen schon so speicherfressend ist, graut mir schon vor der eigentlichen Aufgabe mit den Daten.

Danke jedenfalls für deine Ratschläge.

Re(8): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:53:31 GMT

Werd ich mir alles mal ansehen - ich bin ja jetzt ordentlich mit Vorschlägen überhäuft worden.

Danke an alle, die sich meiner annehmen!

Re(7): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:38:41 GMT

Ach ja, eines muß ich noch reinwerfen...

Du baust also
- einen Parser
- mit fixem "Alphabet"
- mit definierten Aktionen, die er treffen soll, wenn definierte Folgen auftreten...

Wieso höre ich in meinem Hinterkopf Flex/Yacc-Rufe ??? Wäre das möglich ???

Re(6): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:34:46 GMT

Also abgesehen von der MySQL würde ich es auch so sehen...

Wobei Java+DB... Wüste Designpatterns ahead ... Nachdem er nun nicht so viel Coded (so seine Worte)...

Re(5): Java: Parsen großer Dateien

bneu — Thu, 23 Nov 2006 16:33:50 GMT

um den aufwand zu minimieren würde ich allerdings einfach jedes einzelne tuppel in eine mysql-datenbank schmeissen, dann liese sich auch schön abfragen und man müßte sich um die implementierung nicht mehr kümmern.

Re(7): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:32:39 GMT

Weil du schon bei DB warst... Wäre es net sinnvoller, alles in einer DB zu halten ?

Andere Frage:
1.) Du hast also (anonymisiert) ein Alphabet mit den Werten A,B,C,D,a,b,c,d... sind die Case-sensitive ? Könnte also das Bitmuster-speichern nicht echt ordentlich helfen ?

2.) Du erzeugst einfach zu viele Objekte... Also Referenzen. Könntest du nicht einfach die Zeilen speichern ? Und eine Methode providen, die dir auf die Zeile ein Tupel zurückliefert, daß du gleich nach Verwendung wegwirfst ? Wäre langsamer aber Mem-schonender

3.) Brauchst du 100%ig alle Tupel ? Oder kannst du die Relevanten werte nicht aufaggregieren ?
Beispiel: Wenn du Durchschnittswerte berechnen willst, kannst entweder alle Werte addieren und durch die Anzahl dividieren (=der einfache aber "teure" Ansatz... Denn dann mußt alle Werte speichern) - oder immer nur den Durchschnitt speichern und jeden neuen Wert gewichtet dazu"durchschnitten"... dann mußt dir nur die aktuelle Position und den bisherigen Durchschnitt merken - also fix 2 Werte, egal ob du den Durchschnitt über 10 oder 10 Mio werte baust...

Re(7): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:32:39 GMT

Re(5): Java: Parsen großer Dateien

nergal — Thu, 23 Nov 2006 16:30:09 GMT

char = 2x bytes

Re(4): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:29:43 GMT

Ich komm beim Index grad mal mit gut Integer aus.

Und Char hat doch Bytegröße?

Re(8): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:28:49 GMT

Nein. toArray benötigt dieses leere Array, sonst wandelt er mir die ArrayList nicht um, aber das scheint nun eh hinfällig geworden zu sein.

Re(3): Java: Parsen großer Dateien

nergal — Thu, 23 Nov 2006 16:27:40 GMT

Und mit 'byte' für alle drei Parameter kommst Du nicht über die Runden? Wäre eine deutliche Ersparnis!

Re(6): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:22:56 GMT

Wenn er eine Leerzeile hat, überprüft er, ob über haupt noch was kommt, oder noch eine Leerzeile - wenn dem so ist, dann mach ich aus meiner ArrayList ein Array - das geht so weit ich weiß nur über diesen Weg. Tupel[0] würde mir ja nicht das zurüggeben, was ich will.

Der Teil ist auch noch nicht so... naja...

Re(11): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:19:19 GMT

Hab grad nachzählen lassen - sind nur 79 Mio Tupel.

Re(6): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:18:06 GMT

Das Problem ist, daß ich zu weiteren Berechnungen wieder alle Tupel brauche - is a Krux.

Re(4): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:16:56 GMT

Guter Ansatz...

Bei einem 4-Bit-Alphabet könnte er als Kompromiß noch immer 50% sparen und trotzdem einfach operieren...

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 16:16:34 GMT

>Sourcecode für die TupelKlasse

Tupel(char a, int positionA, char b, int positionB){
		this.a = a;
		this.b = b;
		this.posA = positionA;
		this.posB = positionB;
	}

Mehr gibts da nicht.

>hast dich schon mit einem Profiler

Das steht als nächstes auf dem Plan.

Re(5): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:14:56 GMT

Diese Tupelfolgen, die du erkennen willst...
Wäre es möglich, nur diese zu speichern ?

Wäre es zB Denkbar, daß dein Algo so ungefähr so aussieht:

Lies_10_Zeilen_ein
suche_tupel_in_den_10_zeilen_und_speicher_nur_diese();

do {
  schmeiß_eine_zeile_weg
  lies_eine_dazu
  ist_ein_tupel_in_der_letzten_zeile_dazugekommen()
}
while not eof

Wo ich hinwill:
Scheinbar liest du alle Daten ein und arbeitest dann damit.
Was du aber "brauchst" ist mehr so ein streaming-Algo, der einfach ein paar Zeilen liest, interessante auswertet (und vielleicht gleich behandelt) - und praktisch nur das allerallernötigste Speichert...

Re(10): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 16:08:32 GMT

Hmmm.... AFAIK wird bei Array-Operationen immer kopiert... Hier zwar wohl shallow, aber trotzdem.. .

Trotz allem sind die 160 Mio Tupel sein Problem - AFAIK.

Re(3): Java: Parsen großer Dateien

bneu — Thu, 23 Nov 2006 16:02:09 GMT

aber kommen außer a-d und A-D noch andere Zeichen vor? Sonst kommt man ja mit 3Bit je Zeichen aus und das sind immerhin 3/8 der Datenmenge.

also statt 1,5gb nur

0,56gb

ist aber dann mit der kodierung im byte-array wesentlich umständlicher

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:55:12 GMT

Dieses Tupel[] hätte bei meiner 160MB Datei einen Speicherbedarf von ~1.5GB - ich weiß nicht, wie ich dann die weiteren Operationen auf diesem Array durchführen soll.

Re(4): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:53:31 GMT

Das sind Teile eines Sequencealignments (DNA/Protein) - die sind leider so lang.

Das Tupel brauch ich, da ich gewisse Tupelfolgen als "Signale" erkennen möchte und die Bewertung eben nur "pro Tupel" möglich ist.

Die einzelnen Blöcke werden später als "ein Block" betrachet, allerdings liegen zwischen diesen Blöcken Indexsprünge und zusätzlich gibt es auch Stellen, an denen der Index nicht hochgezählt wird:


 1  2  3     4  5  6 | 18 19 20
 A  B  C  -  B  C  A |  B  C  A
 A  B  C  A  B  C  A |  B  -  A
10 11 12 13 14 15 16 | 33    34

(Zwei Blöcke, die später als Tupelfolge verwendet werden soll(t)en.)

Re(4): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:53:31 GMT


 1  2  3     4  5  6 | 18 19 20
 A  B  C  -  B  C  A |  B  C  A
 A  B  C  A  B  C  A |  B  -  A
10 11 12 13 14 15 16 | 33    34

(Zwei Blöcke, die später als Tupelfolge verwendet werden soll(t)en.)

Obs ne Möglichkeit wär, mir eine Menge möglicher Charkombinationen zu bestimmen und dann nur Referenzen zu speichern? Also wär dann ein Tupel 2 int + eine Referenz lang... sofern das was sparen würd.

Re(3): Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 15:42:18 GMT

Nun ja...

Du hast also ein 160MB-File. Wenn ich es richtig verstanden habe, merkst du Dir zu jedem Teil da drinnen 2 chars und 2 Ints - also 10 Bytes und den Objectheader... Krass viel.

Die Frage ist, ob du das echt alles so brauchst... Oder ob du nicht dieselbe Aufgabe einfacher, eleganter und Platzsparender lösen könntest....

Beispiel:
Angenommen, du merkst dir zu jedem Zeichen die X- und Y-Koordinate... Dann würde ich mir einen Array von Zeilen machen - und mit die Zeile/Spalte immer dynamisch holen anstatt alles vorab wegzuspeichern...

Was machst denn genau mit den 160 Mio Tupeln ???

Re: Java: Parsen großer Dateien

nergal — Thu, 23 Nov 2006 15:34:08 GMT

Warum serialisiert Du Tupel nicht und schreibst auf die Harddisk - natürlich nicht pro Tupel aber in Blöcken. Die kannst Du ja dann wieder einlesen in ein Array dessen Größe Du kennst!

Re(9): Java: Parsen großer Dateien

Somnatic — Thu, 23 Nov 2006 15:26:57 GMT

Ich habe den verdacht, dass die ArrayList ziemlichen Overhead erzeugt. Versuch die mal wegzulassen (ja, dann musst halt vorher mal schnell durchrennen, oder kann das nicht eh der BufferedReader sagen?).

Kannst du Strings der Reihe nach in einem Array ablegen, oder sollen sie "logisch" voneinander getrennt sein?

Ich würde sagen - probier mal die Lösung ohne ArrayList, wirklich nur ein Array fester Größe und gut ists.

Was nämlich bei dem ToArray() passiert will ich mir gar nicht vorstellen - ich befürchte dass er da erst recht eine Kopie erstellen wird *graus*

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:26:43 GMT

Vector und Liste hatte ich grad getestet - da ist kein Unterschied spürbar.

>Anderer Punkt: Für jedes Byte da drin entstehen 12 Bytes+Objectheader ?
>Brauchst du das echt so ??? Kannst du nicht stattdessen aggregierte
>Zustände speichern ???

Be easy on me - ich bin kein geübter Coder und muß deswegen fragen: Aggregierte Zuständ? Geht das in Richtung Datenbank?

Re: Java: Parsen großer Dateien

Linux_Sucks — Thu, 23 Nov 2006 15:21:03 GMT

Hmmm... Habe mich da noch nicht viel befaßt, aber Array-Operationen sind per se mal net so super...

Bist schon mal auf andere Collections-Klassen ausgewichen ? Vector basiert ja auf Arrays, aber vielleicht ist ja eine List weit besser in deinem Falle ???

Anderer Punkt: Für jedes Byte da drin entstehen 12 Bytes+Objectheader ?
Brauchst du das echt so ??? Kannst du nicht stattdessen aggregierte Zustände speichern ???

Re(8): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:19:15 GMT

Gut, die Integerzeile die über den Zeilen steht (besteht nur aus Anfangsidizes für jeweils eine der Zeilen) hab ich jetzt mal rausgelassen.

3 5
ABCABCABCABC
ABCABCABCABC

=> Zeile 1 Zeichen 1 bekommt also Index 3 und Zeile 2 Zeichen 1 den Index 5 - und dann wird bis zum Ende des Blocks hochgezählt.

>Warum weisst du am Anfang nicht wieviele Zeilen es sind?

Gut, ich könnte natürlich durch die Datei laufen und mir die Zeilenanzahl berechnen, aber spart das wirklich so viel Speicher? Wie gesagt, wenn ein Tupel 10x soviel Speicher benötigt, wie 2 Zeichen in der Datei, dann wird das ja auch bei einem Feld fester Länger ein großer Speicherbedarf.

Ich tendiere langsam wirklich dazu, das File irgendwie zu splitten - den die Performance bis zu einem bestimmten Zeitpunkt halte ich für recht gut.

Dann müßte ich halt noch scharf nachdenken, wie es dann weitergeht. Ich möchte nur sicher sein, daß ich da keine groben Schnitzer drinnen habe, die das Problem bringen, oder ob das Problem einfach von der Datenmenge her rührt.

Re(7): Java: Parsen großer Dateien

Somnatic — Thu, 23 Nov 2006 15:10:03 GMT

Also es sind immer 2 Zeilen, die zusammengehören?

Wie sind da die Integers drin?

Warum weisst du am Anfang nicht wieviele Zeilen es sind?

Re(6): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:07:16 GMT

Oh - Mistverständnis.

B:

AbbAcDcA
ABBACDCa

AbbAcDcAABBACDCa
AbbAcDcAABBACDCa

AbbAcDcAABBACDCaAbbAcDcAABBACDCa
AbbAcDcAABBACDCaAbbAcDcAABBACDCa

AbbAcDcAABBACDCa
AbbAcDcAABBACDCa

AbbAcDcAABBACDCaAbbAcDcAABBACDCaAbbAcDcAABBACDCa
AbbAcDcAABBACDCaAbbAcDcAABBACDCaAbbAcDcAABBACDCa

Wobei das nicht wirklich immer Wiederholungen sind, das Alphabet größer und eben unterschiedlich viele "Blöcke".

Re(6): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:07:16 GMT

Oh - Mistverständnis.

ZB:

AbbAcDcA
ABBACDCa

AbbAcDcAABBACDCa
AbbAcDcAABBACDCa

AbbAcDcAABBACDCaAbbAcDcAABBACDCa
AbbAcDcAABBACDCaAbbAcDcAABBACDCa

AbbAcDcAABBACDCa
AbbAcDcAABBACDCa

AbbAcDcAABBACDCaAbbAcDcAABBACDCaAbbAcDcAABBACDCa
AbbAcDcAABBACDCaAbbAcDcAABBACDCaAbbAcDcAABBACDCa

Wobei das nicht wirklich immer Wiederholungen sind, das Alphabet größer und eben unterschiedlich viele "Blöcke".

Re(3): Java: Parsen großer Dateien

Somnatic — Thu, 23 Nov 2006 15:04:38 GMT

Ich hab eben keinen Plan, wie ich das alternativ machen kann.

Stückerlweise

Kommt halt drauf an was du nacher damit anstellen willst

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:04:03 GMT

Das ToArray wird erst am Schluß ausgeführt - das könnte dann die nächste Baustelle sein, ist mir auch klar geworden, aber so weit komm ich eben gar nicht erst.

>generell solltest vielleicht das kozept, das ganze file in den speicher zu lesen,
>überdenken...

Ich hab eben keinen Plan, wie ich das alternativ machen kann.

Re(5): Java: Parsen großer Dateien

Somnatic — Thu, 23 Nov 2006 15:03:43 GMT

ähm .. ich meinte eher die datei, die du einliest

Re(4): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:00:53 GMT


try {
	br = new BufferedReader(new FileReader(new File(fileName)));
			
	// while buffer not empty
	while (br.ready()){

		// discard empty lines, multiple empty lines are handled as EOF
		check = br.readLine();
		while (check.length()==0){ 
			if(br.ready()){
				check = br.readLine();
			}else{
				// make a tupel array
				tupels = al.toArray(new Tupel[0]);
				//return the tupel array
				return tupels;					}
		}

		partA = br.readLine().toLowerCase();
		partB = br.readLine().toLowerCase();
		
		// put both chars at position i as a tupel into the array list
		for (int i = 0; i < partA.length(); i++){			                    
			// create new tupel and add to arraylist
			Tupel tup = new Tupel(...);
			al.add(tup);	
		}
}
} catch ...
	
// make a tupel array
tupels = vt.toArray(new Tupel[0]);
// return tupel array
return tupels;

Re(4): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:00:53 GMT


try {
	br = new BufferedReader(new FileReader(new File(fileName)));
			
	// while buffer not empty
	while (br.ready()){

		// discard empty lines, multiple empty lines are handled as EOF
		check = br.readLine();
		while (check.length()==0){ 
			if(br.ready()){
				check = br.readLine();
			}else{
				// make a tupel array
				tupels = al.toArray(new Tupel[0]);
				//return the tupel array
				return tupels;					}
		}

		partA = br.readLine().toLowerCase();
		partB = br.readLine().toLowerCase();
		
		// put both chars at position i as a tupel into the array list
		for (int i = 0; i < partA.length(); i++){			                    
			// create new tupel and add to arraylist
			Tupel tup = new Tupel(...);
			al.add(tup);	
		}
} catch ...
	
// make a tupel array
tupels = vt.toArray(new Tupel[0]);
// return tupel array
return tupels;

Re(4): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 15:00:53 GMT


try {
	br = new BufferedReader(new FileReader(new File(fileName)));
			
	// while buffer not empty
	while (br.ready()){

		// discard empty lines, multiple empty lines are handled as EOF
		check = br.readLine();
		while (check.length()==0){ 
			if(br.ready()){
				check = br.readLine();
			}else{
				// make a tupel array
				tupels = al.toArray(new Tupel[0]);
				//return the tupel array
				return tupels;					}
		}

		partA = br.readLine().toLowerCase();
		partB = br.readLine().toLowerCase();
		
		// put both chars at position i as a tupel into the array list
		for (int i = 0; i < partA.length(); i++){			                    
			// create new tupel and add to arraylist
			Tupel tup = new Tupel(...);
			vt.add(tup);	
		}
}
} catch ...
	
// make a tupel array
tupels = vt.toArray(new Tupel[0]);
// return tupel array
return tupels;

Re: Java: Parsen großer Dateien

adhoc — Thu, 23 Nov 2006 14:53:22 GMT

problem ist wohl alles, wo daten im speicher kopiert werden (mit dem ToArray hast den ganzen datenhaufen vielleicht doppelt im speicher (oder dreifach))

(generell solltest vielleicht das kozept, das ganze file in den speicher zu lesen, überdenken...)

Re(3): Java: Parsen großer Dateien

Somnatic — Thu, 23 Nov 2006 14:46:43 GMT

kannst evtl. mal einen kurzen Ausschnitt aus der Quelldatei posten? Kann mir das grad nicht vorstellen ..

Re(2): Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 14:41:42 GMT

> Kanns sein dass die ArrayList einen gewaltigen Overhead hat?

Das ist eine gute Frage... Bei Eingabegröße 1MB hat das Tupel[] am Schluß ~10MB - ich denke einfach, daß das von der Größe her schon ein Problem ist.

>Das ArrayList.toArray() ist sicher auch nicht ideal.

Soweit (also bis zum Schluß) kommts ja leider nicht.

>Warum nicht gleich ein array mit fixer Größe erstellen, die Zeilenanzahl
>ist ja nicht wirklich dynamisch, oder?

Es sind pro Datei unterschiedlich viele Doppelzeilen mit unterschiedlicher Länge - ich kann leider nicht mit festen Größen rechnen.

Re: Java: Parsen großer Dateien

Somnatic — Thu, 23 Nov 2006 14:35:47 GMT

Kanns sein dass die ArrayList einen gewaltigen Overhead hat?

Das ArrayList.toArray() ist sicher auch nicht ideal.

Warum nicht gleich ein array mit fixer Größe erstellen, die Zeilenanzahl ist ja nicht wirklich dynamisch, oder?

Java: Parsen großer Dateien

m3t4tr0n — Thu, 23 Nov 2006 14:25:19 GMT

Hallo!

Ich hab ein Problem beim Parsen von großen Datein (160MB++). Eine Datei enthält mehrere String-Doppelzeilen, aus denen für jede Position Tupel-Objekte (= zwei Chars, zwei Integers) erstellt werden sollen. Diese Objekte sollen in ein Array, was dann die Ausgabe des Parsevorgangs bilden soll.

Das Problem - der Speicher. Mit "java -Xmx2600M" tuts das 64-bit Linux recht weit, aber kurz vor Ende der Datei ist Schluß (Prozess hängt mit 2.7GB Speicher und 0% CPU). Ist Xmx unter 1024M krieg ich sofort einen Fehler mangels Heap Space. Mit kleinen Testdateien funktioniert der Parser hingegen problemlos.

Die Objekte zwischenzuspeichern wäre vielleicht eine Idee, ich weiß aber nicht, wie ich dann am Ende das ganze wieder zu einem Array zusammensetzen soll.

Irgendwelche Ideen, wie man das ohne Hardwareaufrüstung im bösen Ausmaß machen kann?

Grober Vorgang:

BufferedReader <- FileReader <- File
While (BufferedReader nicht leer) {
   Zeile 1 = BufferedReader.readLine()
   Zeile 2 = BufferedReader.readLine()
      For (Zeilenlänge) {
          ArrayList.add(New Tupel(...))
      }
}
Tupel[] = ArrayList.toArray
return Tupel[]