Hallo,
habe gerade mal in einem Script (http://lamp.epfl.ch/~michelou/links/java_se/docs/mjp…)
über Performance und Java gelesen.
Dort kam u.a. der Bergriff Objektpool. Leider wurde das nicht näher erklärt.
Kann mir jemand sage was damit gemeint ist und wie man das anlegt/verwaltet.
Weiteres Thema war cachen von Objekten z.B. Bildern in Java.
Ich denke damit ist gemeint die Objekte in einer Hashtabelle, LinkedList,… oder einem Array zu verwalten. Oder ?
Danke
Albert
Moin
habe gerade mal in einem Script
(http://lamp.epfl.ch/~michelou/links/java_se/docs/mjp…)
über Performance und Java gelesen.
Man muss beim Tunnen von java verdammt gut aufpassen woher man seine Informationen bezieht. Das Tunnen von 1.1’er code basiert auf ganz anderen Annahmen als das tunnen von 1.3 oder 1.4’er Code. Und der Begriff Objectpool stammt aus der 1.1’er Zeit. Das wirkt bei neueren JVMs nicht mehr so stark wie damals. (Es wirkt schon noch, aber der Performanceverteil rechtfertigt nur noch selten den Aufwand)
Dort kam u.a. der Bergriff Objektpool. Leider wurde das nicht
näher erklärt.
Es gibt Objecte die man immer wieder verwenden kann. Z.B. Vector, Hashtable. Man kann nun ein paar davon auf Vorrat anlegen und zentral in einem „Pool“ verwalten. Immer wenn ein Programmteil einen Vector braucht frag es bei dem Pool nach einem vector (anstelle von „new Vector()“). Nach benutzen gibt es den wieder zurück. Der Pool löscht den Inhalt des Vector und nimm ihn wieder in seine Liste auf.
Vorteil: es werden weniger Objecte erzeugt (per new XYZ) und es fallen weniger Object für gc an. Beides war in den ersten java-versionen extrem langsam und nervtötend. Inzwischen gehts schon viel schneller (besonders gc hat mächtig zugelegt).
Weiteres Thema war cachen von Objekten z.B. Bildern in Java.
Objecten != Bilder. Worum gehts genau und über welche Version reden wir ?
cu
Hallo,
mich interessiert allgemein das Theam Performance bzw. Tips und Tricks dazu. Ich arbeiter zur Zeit mit der Verson 1.4.2 .
Bzgl. Cache habe ich momentan keine konkrete Anforderung. Mein Theam ist zur Zeit Daten über ein Servlet von einer DB lesen und diese in einem Baum im Applet anzeigen. Damit wir nicht zu viele Daten über das Netz trasportieren müssen laden wir die Daten bei Bedarf d.h. wenn jemand auf den entspr. Knoten klickt vom Server nach. Icons, die im Baum angezeigt werden sollen laden wir bei der ersten Anfrage in eine Hashtabelle und dann nur noch aus dieser.
Momentan ist unser Baum noch nicht sehr groß. Über Nacht habe ich einmal einen Test gemacht. Der Baum wurde über eine Schleife 20000 mal
von Server neu geladen D.H. löschen des Models, und laden von jedem Level des Baums bis der Baum vollständig (bis zum letzten Blatt) geladen war.
Ich wollte dabei den Speicher beobachten.
Aufgefallen ist mir, dass der Prozess iexplorer.exe ständig mehr Speicher benötigte. Heute morgen waren es ca. 470.000K. Die java.exe hatte ca 25.000K. Das Programm ist irgendwann/irgendwo mit „OutOfMemory“ abgebrochen.
Mit würde nun z.B. interessieren wie man hier vorgeht und optimiert.
Albert
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Java-Knigge gefällig ?
Guten Morgen.
Ich will’s mal so sagen: es hängt auch vom Programmierstil selbst ab wie schnell ein java-Programm läuft und wieviele Resourcen es beansprucht. Und der verwendeten HW, wenn DB-Operationen dazukommen… Michael Wiedekind vom Javamagazin z.B. hat sich dieses Themas angenommen. Stichwort: Java-Knigge ("verdammt: http://groups.google.de/groups?q=Java-Knigge&hl=de&l…)
oder http://www.mathema.de/guidelines http://www.entwickler-forum.de
In diesem Sinne wünsche ich ein effektives Programmieren
mfg M.L.
Moin
Aufgefallen ist mir, dass der Prozess iexplorer.exe ständig
mehr Speicher benötigte. Heute morgen waren es ca. 470.000K.
Die java.exe hatte ca 25.000K. Das Programm ist
irgendwann/irgendwo mit „OutOfMemory“ abgebrochen.
Ich glaub der IE hatte den gesamten Schmoder (also alle Durchläufe) noch im RAM. Viel Spass…
Mit würde nun z.B. interessieren wie man hier vorgeht und
optimiert.
Zuerst testen ob’s nur den IE betrifft oder auch andere.
cu