Performanceverlust beim Schreiben von ResultSet in txt Datei

[Elizafa]

Hallo erstmal!

Ich tüftel zur Zeit an nem kleinen Programm um regelmäßig Abfragen durch Datenbanken zu jagen... (Fehlerhafte Datensätze ausfindig machen)
Das Ergebnis stell ich zur zeit in einfachen html Tabellen dar - was an sich keinerlei Probleme bereitet ABER ich bemerke starke Performanceverluste...
Derzeit bau ich mir ja einen sehr langen String zusammen der immer wieder in den Arbeitsspeicher gelegt wird....(siehe Code)
Hat vielleicht jemand eine Idee wie man das Umgehen könnte? Und zum Beispiel eine Datei in Echtzeit schreiben kann? Irgendwie steh ich da etwas auf dem Schlauch :/ Vielleicht gibt es ja auch noch ganz andere Ansätze die das Problem geschickt umgehen?



Innerhalb dieser Schleifen entstehen bei zunehmender Stringlänge extreme Performanceverluste..

while (result.next()){
    		htmlCode = htmlCode + "\n \t <tr> \n \t \t <td> \n \t \t" + id + "\n \t \t </td> \n \t \t <td>";
    		int i = 1;
    		while(i<=spalten){
    		            if (i==spalten)
    		            htmlCode = htmlCode + "\t \t" + result.getString(i) + "\n \t \t </td> \n";
    		            else
    		            htmlCode = htmlCode + " \t \t" + result.getString(i) + "\n \t \t </td> \n \t \t <td> \n";
    		            i++;
    		}

    	}
    result.close();
    htmlCode = htmlCode + htmlend;

 

[nrg]

nimm einen StringBuilder. Strings sind in java immutable, d.h. bei Stringverkettungen werden immer neue Objekte erzeugt (diese werden auch nie durch den GC bereinigt, weil sie durch den StringPool permanent referenziert werden!)

 

[Elizafa]

Danke nrg!
Hab es direkt mal umgeschrieben und siehe da - kein Performanceverlust mehr

 

[SlaterB]

nimm einen StringBuilder. Strings sind in java immutable, d.h. bei Stringverkettungen werden immer neue Objekte erzeugt (diese werden auch nie durch den GC bereinigt, weil sie durch den StringPool permanent referenziert werden!)

hast du eine Begründung für das mit dem Stringpool + GC? klingt nicht glaubwürdig,
Strings werden doch alle Nase lang in Programmen erzeugt,
das wäre doch ein bekannter Exitus in jedem länger laufenden Prozess

edit:
dass die Erzeugung unnötige Arbeit ist und mit StringBuilder besser wird stimmt natürlich fraglos,
allein dass bei solch schlechten Schleifen Minuten gearbeitet wird zeigt schon die gute Arbeit des GC,
den Speicher vollzumüllen schafft man in Sekunden, damit es ewig weiterläuft müssen die alten Strings alle weichen

 

[nrg]

hast du eine Begründung für das mit dem Stringpool + GC? klingt nicht glaubwürdig,
Strings werden doch alle Nase lang in Programmen erzeugt,
das wäre doch ein bekannter Exitus in jedem länger laufenden Prozess

Also auf Literale trifft das auf jedenfall zu (StringLiteralPool). Bei Verkettungen müsste das afaik der StringConstantPool sein und somit dort ebenfalls zutreffen (ohne das jetzt nochmal irgendwo nachgelesen zu haben - grad wenig zeit)

Hatte hier mal einen Thread dazu:
http://www.java-forum.org/allgemeine-java-themen/118286-speicherbereinigung-pool.html

 

[SlaterB]

du hast dort zwar auch durch Schleifen verkettete Strings angesprochen, aber das ging eher unter, wurde nie direkt kommentiert,

gecachte Literale sind ganz klar im Quellcode stehende Strings "hallo" und meinetwegen auch direkte Zusammensetzungen "hal"+"lo",
das als "hallo" zu interpretieren, so schlau ist der Compiler noch, all das kann geklärt werden bevor das Programm überhaupt läuft,

aber alles was erst zur Laufzeit passiert, das kommt standardmäßig nicht in den internen Pool,
sondern auf den Heap wie im anderen Thema auch diverse Male erwähnt,

dass == stattt equals nicht funktioniert ist ein weitere Hinweis gegen den Pool, für eigene Objekte

 

[irgendjemand]

es würde sogar NOCH einfacher gehen ...

in dem man sich einen PrintStream nimmt *natürlich mit unterliegendem FileOutputStream um dierekt in die datei zu schreiben* und dann jede zeile direkt in die datei schreibt ... ansatt sich erst einen langen string zusammenzubauen und diesen dann auf einmal in das file zu schreiben ...
würde zumindest die performance noch steigern ...

 

[SlaterB]

kommt drauf an wie geschrieben wird, direkt in einen FileWriter mit einer Festplattenoperation pro Zeile wäre nicht gut,
schneller als das verrückte String + String aber natürlich allemal

mit einem BufferedWriter wie ihn ein PrintStream trotz schlechter Benennung intern auch verwendet wird gecacht,
recht ähnlich dem StringBuilder, aber nur auf bestimmte Größe beschränkt,
ja das kann man letztlich doch als effektiver ansehen

 

[irgendjemand]

hmm .. mir ist jetzt PrintStream nur in den sinn gekommen da dieser *zumindest was sockets angeht wo ich diesen stream hauptsächlich verwende* die daten dierekt an den unterliegenden OutputStream *welcher form und implementierung auch immer* weiterreicht ...

das es rein theoretisch nicht gerade "günstig" ist da bei schlechter implementierung jedesmal dierekt bis zur platte weitergeleitet wird und dadurch natürlich viele zugriff und damit verbunden auch fragmentierung entstehen ... ja .. is mir bewusst und sehe ich ja auch ein ... aber sollte dennoch eine der "performanteren" arten sein ...

das man natürlich mit einem gewissen cache arbeiten sollte um gerade die plattenzugriffe und die fragmentierung in den griff zu bekommen sehe ich persönlich auch als "schöner" an ... aber ich denke das es TO hier vor allem auf den hohen performance verlust beim zusammenbauen des String ankam als auf die hardware-auslastung =D

 

[SlaterB]

String + String geht gar nicht, soweit ganz klar, aber wenn hier schon Performance Thema ist dann kann man wirklich erwähnen,
dass im Arbeitsspeicher zusammensetzen besser ist als mit vielen Dateizugriffen
(unter Abwägung aller Details, etwa dass der Gesamtstring aus dem Arbeitsspeicher irgendwann ja auch in die Datei muss, vielleicht wieder neu gestückelt..)

 

[...ButAlive]

String + String geht gar nicht, soweit ganz klar

So pauschal kann man das nicht sagen.

String test = "Hello"+ " " + "World"+"!";

Wird kompiliert zu:

StringBuilder tmp = new StringBuilder();
tmp.append("Hello");
tmp.append(" ");
tmp.append("World");
tmp.append("!");
String test = tmp.toString();

Soweit noch kein wirkliches Problem. Das würde man per Hand mit einem StringBuilder auch so hinschreiben. Das Problem fängt erst bei Schleifen an, denn

String[] array = {"Hello"," ","World","!"};
String result = "";
for(String s : array){
   result += s;
}

wird kompiliert zu:

String[] array = {"Hello"," ","World","!"};
String result = "";
for(String s : array){
   StringBuilder tmp = new StringBuilder(result);
   tmp,append(s);
   result = tmp.toString();
}

Wenn man das per Hand schreibt kommt ungefähr sowas raus:

String[] array = {"Hello"," ","World","!"};
StringBuilder tmp = new StringBuilder(result);

for(String s : array){
   tmp,append(s);
}

String result = tmp.toString();

Der +-Operator bei Strings würde in Schleifen, bei jedem Durchlauf, ein neues StringBuilder-Objekt anlegen und darauf toString aufrufen. Das ist nicht wirklich nötig und sollte vermieden werden.

Also der +Operator ist außerhalb von Schleifen total ok und sollte im Sinne der Lesbarkeit verwendet werden.

Wird der String in einer Schleife zusammengebaut sollte auf den +Operator verzichtet werden.

Um den Bogen wieder zurück zum ursprünglichen Thema zu spannen, die Lösung in den BufferedWriter zu schreiben ist die Beste, denn der BufferedWriter kennt die optimale Puffergröße (das was im Arbeitspeicher gehalten werden kann und die Größe der Blöcke im Filesystem).