S: Passenden "Container" for ByteBUffer Pool

[tuxedo]

Hallo zusammen,

um mein SIMON etwas performanter zu machen, möchte ich die ByteBuffer die ich ständig benutze/neu anlege cachen.

Und jetzt suche ich den passenden "Container" für meine ByteBuffer.

Was ich mit meinem Pool realisieren will:

Er soll eine fixe Anzahl von ByteBuffer Objekten bevorraten. Die Kapazität der ByteBuffer ist dabei nicht festgelegt, d.h. es dürfen mehrere Elemente mit selber Kapazität in Pool vorhanden sein. Aber ebenso gut können es auch lauter unterschiedliche Größen sein.

Ist der Pool voll und soll ein neuer ByteBuffer hinzugefügt werden, soll der älteste aus dem Pool entfernt werden um für den neuen Platz zu machen.

Im Prinzip bräuchte ich eine "LinkedList" die ein Key-Value-Paar verkraftet, wobei der key mehrfach vorkommen darf. Der Key wäre dann die Größe des jeweiligen ByteBuffers, und value dann der ByteBuffer selbst.

Am besten sollte sich die Liste noch nach dem ersten vorkommen eines Keys (aus einer bestimmten Richtung eben) fragen lassen.


- Nach was muss ich suchen wenn es sowas schon gibt?
- Wenn's sowas noch nicht gibt: Was würde sich zu so einer Liste am besten kombinieren lassen?

Das ganze sollte nach Möglichkeit recht performant sein und intern nicht ne Menge Overhead erzeugen.

Any ideas?

- Alex

 

[tuxedo]

Okay,mit kam grad eben selbst ne Idee, allerdings gibts da noch einen Haken:

Ich nehme ne HashMap als Basis. Als key trage ich die Größe des ByteBUffers ein. Damit es mehrere ByteBuffer mit der gleichen größe geben kann, ist "value" der HashMap eine ArrayList. Damit wird's prinzipiell gehen.

Aber wie komme ich jetzt an den ältesten ByteBuffer in diesem Konstrukt (brauch ich um den ältesten Eintrag im Pool zu entfernen wenn er droht überzulaufen)??

- Alex

 

[ms]

Du könntest parallel zu der HashMap eine Queue verwenden.
Beides, die HashMap und die Queue in einer Klasse kapseln und du hast deinen ByteBufferPoolStack.

ms

 

[Marco13]

Die http://java.sun.com/javase/6/docs/api/java/util/LinkedHashMap.html bietet einen Speziellen Konstruktor für die implementierung eines LRU-Caches an (steht oben in der Doku). Wenn man in dieser Map dann nur http://java.sun.com/javase/6/docs/api/java/lang/ref/SoftReference.html speichert, behält der Cache immer so viel Speicher, wie möglich - und gibt die Objekte automatisch wieder frei, wenn Speicher benötigt wird.

 

[tuxedo]

Habs bis jetzt so gelöst:

Eine HashMap: Key=Größe des ByteBuffers, Value=ArrayList mit den ByteBuffers in der größe gemäß des "Key".

Parallel dazu hab ich eine LinkedList in der ich mir merke, welche Buffergrößen ich in den Pool gegeben habe. Damit weiß ich dann immer, welche Größe ich kürzlich eingefügt habe, und welche ich seit längerem nicht mehr benutze. Anhand dieser Liste sehe ich auch, wieviele ByteBuffer ich im Pool drin hab. Ist die Liste beim einfügen eines neuen BUffers schon "maxSize" groß, so fliegt eine Instanz des Buffers mit der am längsten nicht mehr benutzten Größe aus der ArrayList in der Map. Ist die Arraylist dann auch noch leer, fliegt die ArrayList auch noch raus.

Im Test funktioniert das schon prima. Aber irgendwo hab ich noch den Wurm drin, weil in meiner Anwendung krieg ich hier und da immer mal wieder einen Buffer nicht richtig gefüllt, und das obwohl ich immer brav clear() drauf ausführe.

Na mal schauen.

Die Idee mit der SoftReference ist vermutlich nicht schlecht. Nur will ich nicht die ArrayLists in der Map weg haben, sondern einzelne Einträge in der List. Und da auch nur die, die ich seit längerem nicht gebraucht habe. Mal sehen ob ich da noch was drehen kann..

- Alex

 

[Marco13]

Hm :? Solche Daten parallel zu halten ... Fändest du es nich günstiger, dir eine Klasse "BufferCache" zu schreiben, die das Verhalten durch wenige, klar spezifizierte Methoden anbietet? Die kannst du dann entweder so implementieren, dass sie eine HashMap mit ArrayLists<ByteBuffer> und eine LinkedList enthält, oder ... (was IMHO erstmal einfacher erscheint) ... eine LinkedHashMap (die ja schon eine Mischung aus HashMap und LinkedList IST) und ArrayLists<ByteBuffer> oder (optional!) ArrayLists<SoftReference<ByteBuffer>> .... !?

Der Bug.... Hm ... "clear()" bewirkt AUCH das gleiche wie ein "rewind()"?! (Letzteres vergess' ich gerne, und dann füllt/liest er halt nicht richtig.... fiel mir nur als erstes ein....)

 

[tuxedo]

Der Bug war ein anderer. Sollte eben nicht mehrfach versuchen einen BUffer zurück in den Cache zu schieben.

Hab die Klasse jetzt fertig (für mich mit nur 2 Methoden - eine für get und eine für putBack - abstrakt genug). Aber die gewünschte mehr-performance kam dabei nicht raus. Hab nochmal mit meinem Profiler reingeschaut: In der Tat ist nicht das erzeugen der ByteBuffer das Nadelöhr. Ist wieder (oder immer noch) die serialisierung: readObject() und writeObject() auf den Object*Streams dauert so lange.

Wenn ich doch bloß dahinterkommen würde warum das bei RMI nicht so lange dauert (und soweit ich das gesehen hab cached der Object*Stream bei RMI auch nix, der wird jedesmal neu erzeugt).

Naja, soweit mal danke für die Tipps und Hilfe.

- Alex