3.5 Mio. Objekte

[julari]

HAllo zusammen!

Ich habe lange in Google geschaut, aber keine Antwort auf mein Problem gefunden.
Ich habe folgendes grosses Objekt:

public class Feature extends Spectrum.Peak 
{
    

    public float time = 0;
    public float mass = 0;
    public int charge = 0;
    protected boolean accurateMZ = false;  
    public float kl = -1.0F;
    public float dist = -1.0F;
    public int peaks = 1;
    public boolean skippedPeaks = false;
    public int chargeStates = 1;
    protected String description;
    public int scanFirst;
    public int scanLast;
    public float totalIntensity = 0F;
    public float proportional_intensity=0F;
    public int scanCount = -1;
    public static float MZ_RANGE = .04f;
    public boolean fits_4_6_pattern;
    public boolean fits_0_10_pattern;
    public boolean overlap;
    public int running_scan_number;
    public Feature[] observed_isotopic_pattern;
    public float[] theoretical_isotopic_pattern;
    public int observed_isotopic_pattern_length;
    public int[] exclude_index;
    public boolean rejected;
    public int index;
    public double observed_isotopic_pattern_intensity_sum;
    public float sn;
    public boolean FeatureFragmented;
  }

Davon erzeuge ich nach einlesen eines XML files etwa 3.5 Mio. Stück!
Es gibt natürlich einen memory error in Java (heap space).

Ich muss, um Berechnunge zu machen, diese Features (welche geordnet sind zB nach Masse) komplett durchgehen.
Was kann ich tun um das Speicherproblem zu lösen?

Wenn ich die 3.5 Mio Features auf der Festplatte abspeichere statt in einer ArrayList, dann habe ich eigentlich auch keinen Vorteil,oder? Denn dann muss ich alles auch wieder einlesen und habe anschliessend wieder eine ArrayList<Features> Struktur mit 3.5 Mio. Einträgen.

Oder sehe ich das falsch?
Was kann also tun, um die Daten sukkzessive und am Stück durchzugehen, ohne sie im Hauptspeicher halten zu müssen?

Vielen Dank!

 

[Final_Striker]

Ich würde an deiner Stelle eine Datenbank verwenden.
Kannst ja dann was du brauchst selektieren und berechnen.

 

[Michael...]

Was kann also tun, um die Daten sukkzessive und am Stück durchzugehen, ohne sie im Hauptspeicher halten zu müssen?

Ganz pauschal: die Objekte sukkzessive bzw. nach Bedarf oder nur die relevanten Werte laden. Man wird ja nicht für einzelne Berechnungsschritte alle Objekte gleichzeitig benötigen.

 

[julari]

Hallo!

Vielen Dank. So wie ich es aber auch drehe, ich brauche denke ich schon alle Objekte, denn wenn ich nur ein Teil selektiere, dann fehlt der andere.
Wie würde es denn funktionieren, wenn ich alle Objekte brauche?

 

[langhaar!]

Statt die Berechnungen nach dem Einlesen der Daten durchzuführen machst du das während des Einlesens.
Dazu wirst du vermutlich deinen Einleseroutine ändern müssen und musst statt einem Dom einen Sax Parser nehmen.




Erinnert mich an diesen Fall:
http://www.java-forum.org/java-basics-anfaenger-themen/128145-java-memory-leakage.html

 

[nocturne]

System.gc()

Löst dein Problem.

 

[langhaar!]

Hallo!

Vielen Dank. So wie ich es aber auch drehe, ich brauche denke ich schon alle Objekte, denn wenn ich nur ein Teil selektiere, dann fehlt der andere.
Wie würde es denn funktionieren, wenn ich alle Objekte brauche?

Das hast du falsch verstanden. Du brauchst zwar alle Objekte, aber nicht gleichzeitig.
Wenn du z.B. eine Summe bilden willst, dann brauchst du die laufenden Summe und ein(!) Objekt, von dem du Daten hinzuaddierst.

 

[Andgalf]

System.gc()

Löst dein Problem.

Ich wette dagegen ... Es ist imho keine gute Idee die garbage collection von Hand auszulösen. Die Notwendigkeit dafür zeugt eigentlich immer von einem design problem

 

[langhaar!]

Ich wette dagegen ...

Ich auch.
Wieso sollte eine Garbage Collection dabei helfen, wenn ich mehr Daten in den Speicher laden will, als ich Speicher habe ???:L
Solange Objekte referenziert werden, und das werden sie, werden sie nicht entfernt.

 

[julari]

Puh! Geht das evtl. auch anders als dass ich den XML parser umschreiben muss? Den habe ich nämlich nicht selber geschrieben....

Ich verstehe schon, dass man am besten immer nur einen Teil der Daten in den Speicher laden soll. Problem: Ich weiss vorher immer nicht, wie viele der 3.5 Mio. Features ich einladen soll. Nehme ich zB 1000 Stück, dann kann es sein, dass der 1001. Feature auch noch dazugehört. Das kann ich vorher nicht sehen, wie die Features zusammenhängen.

Es ist so schwer zu erklären......

Das Ausgabgsfile schaut in etwas so aus:
<Scan1>
<Feature1>
<Feature2>
<Feature3>
<Feature4>
......
Scan2>
<Feature1>
<Feature2>
<Feature3>
<Feature4>
......
...........
...........
Scan4000>
<Feature1>
<Feature2>
<Feature3>
<Feature4>
......

Wenn ich daraus die Features herausparse, komme ich auf 3.5 Mio Features in einer ArrayList.

 

[langhaar!]

Puh! Geht das evtl. auch anders als dass ich den XML parser umschreiben muss? Den habe ich nämlich nicht selber geschrieben....

KLar, indem du eine DB nimmst. Dann brauchst du den Parser nicht umschreiben, weil du keinen mehr benutzt

EDIT
Blödsinn. Auch dann musst du den Parser umschreiben, um beim Einlesen die Daten in die DB abzulegen.
Da du nicht alle Daten auf einmal laden kannst, sehe ich keine Möglichkeit, dass du nicht an den Parser musst.

Ich verstehe schon, dass man am besten immer nur einen Teil der Daten in den Speicher laden soll. Problem: Ich weiss vorher immer nicht, wie viele der 3.5 Mio. Features ich einladen soll. Nehme ich zB 1000 Stück, dann kann es sein, dass der 1001. Feature auch noch dazugehört.

Du sollst auch nicht 1000 Stück laden, sondern immer nur 1!
Dann vergleichst du, ob die Features zusammenpassen.

Erst wenn deine Daten nicht sequentiel gelesen werden können, wirst du wohl auf eine DB ausweichen müssen.

 

[SlaterB]

Ich verstehe schon, dass man am besten immer nur einen Teil der Daten in den Speicher laden soll. Problem: Ich weiss vorher immer nicht, wie viele der 3.5 Mio. Features ich einladen soll. Nehme ich zB 1000 Stück, dann kann es sein, dass der 1001. Feature auch noch dazugehört. Das kann ich vorher nicht sehen, wie die Features zusammenhängen.

Es ist so schwer zu erklären......

ohne Erklärung kann dir aber niemand helfen,
gut möglich dass du aus irgendeinem Grund (allein schon um umfangreichere Code-Änderungen zu vermeiden) besser 1001 Objekte gleichzeitig in den Speicher holst,
das könnte vollkommen in akzeptablen Regionen sein wenn der Speicher für hunderttausende reicht,

du kannst dafür deine Verarbeitung mehr oder weniger intelligent machen,
z.B. immer noch einzeln einlesen aber die Objete sammeln,
wenn in der Liste schon x Objekte drin sind, das nächste Objekt y sich aber vom vorherigen unterscheidet,
dann in diesem Moment die gemeinsame Verarbeitung der x Objekte starten, danach die Liste leeren und y einfügen
sowie weiter machen, nächstes Objekt laden

auf solchem Wege könntest du beliebige zusammengehörige Teilmengen verarbeiten,
falls sie in Reihenfolge vorliegen,
und natürlich abgesehen von dem Fall dass eine solche Teilmenge den Speicher übersteigt

 

[bERt0r]

Da dein Objekt ja nur Eigenschaften und keine Methoden besitzt bist du sicher mit einer Datenbank am besten bedient. Wenn du damit wenig Erfahrung hast, schau dir mal H2 Database Engine an. SQL-mäßig solltest du mit Grundkenntnissen auskommen.

 

[irgendjemand]

dein ansatz ist falsch

natürlich brauchst du mit sicherheit ALLE deine objekte ... IRGENDWANN ... aber NIE gleichzeitig

als beispiel sollte man vielleicht mal die arbeitsweise eines rechners in seinen zugrundeliegenden mathematischen fähigkeiten beschrieben

ein computer hat eine gewisse anzahl von operationen *arithmetisch und logisch > ALU , fließkommazahlen > FPU* die er auf eine gewissen anzahl von eingangssignalen anwenden kann ...
du kannst zwar ewiglange befehlsketten schreiben ... in der regel werden aber nie mehr als 3 werte gleichzeitig gebraucht : 1tes register , 2tes register , operation die auszuführen ist

heißt also : egal welche operation du ausführen willst ... du kannst diese *linear gesehen* alle nach ein ander durchführen *mal von multi-threading auf mehrkern-cpus abgesehen* ... und genau das versuchen dir hier alle klar zu machen ...

du musst nicht alle 3,5mio objekte GLEICHZEITIG im speicher halter ... weil du um diese alle gleichzeitig verarbeiten zu können auch min 3,5mio prozessoren bräuchtest ... die du mit sicherheit nicht hast ..

was also zu tun ist das du sequentiell arbeitest und immer nur so wenig objekte wie möglich im RAM hast ... den rest schreibst du raus auf die platte ...
also hast du maximal 4 werte im RAM ... objekt1 , objekt2 , die anweisung was mit den beiden objekten gemacht werden soll und schließlich das ergebnis ... nach dieser verarbeitung schreibst du das ergebnis auch raus auf die platte und entlädst die objekte so das der RAM freigegeben wird ...

 

[fastjack]

Die GC wird Dir wenig helfen, außer wenn Du Objekte nach der Berechnung aus Deiner Collection entfernst, ansonsten hast Du nunmal 3.5M Objekte im Speicher. Die VM wird dann aber die GC irgendwann alleine starten. Meine Erfahrung zeigte, das die GC immer gestartet wird, wenn ich System.gc() aufrufe, aber das ist nicht garantiert.

Beim Parsen zu berechnen ist vielleicht sogar ideal für Dich, außer wenn das ganze dynamisch sein soll, z.B. in einer GUI verwendet wird. Wenn die Berechnungsarten fest sind, würde ich mehrere Berechnungen beim Parsen hintereinander machen machen, also einmal parsen, dabei mehrere Berechnungen anstoßen (daten dabei in verschiedenen Objekten halten).

Ansonsten, wenn es dynamisch sein soll, ab mit den Daten in eine DB.

 

[ARadauer]

Ganz einfach: Java mehr Speicher geben... ich hab hier einen 8 GB rechner 3.5 Mio Objekte... lol... kein problem

java -Xmx2048m -jar deinJar.jar