Generirung CSV

[dngfng]

Hallo,

ich bin in unsern Code über folgende Stelle gestolpert. Da doch einige Zeilen Code zwischen der Buffer beschreibung und den subString liegen hatte ich mich zunächst gewundert ob jemand vergessen hatte sicher zu stellen erst ein Komma nach dem ersten Eintrag gemacht wird.

Sicherlich spart man einige Operationen hierdurch da man nicht jedes mal abfragt ob schon ein Eintrag im Buffer gemacht wurde.

Allerdings finde ich dies doch etwas Unleserlich - was haltet Ihr hier von - glaubt Ihr das dies sich lohnt (es werden wohl so ~1000 Einträge in denn Buffer gemacht).

...
...
StringBuffer data = new StringBuffer();

while(rs.next()) {
    data.append("," + rs.getString(1));
}

...
...

String x = data.toString();

if(data.length()>1) x = x.substring(1);

 

[faetzminator]

das [c]data.append("," + rs.getString(1));[/c] macht alles wieder zunichte.
Besser wär

data.append(',');
data.append(rs.getString(1));

 

[dngfng]

ist schon klar - ich sag ja ich bin über den Code gestolpert und hatte mich doch sehr darüber gewundert. Besonders bin ich mir nicht sicher das der Verlust der leserlichkeit nicht doch wesentlich höher ist als der Performance Gewinn.

 

[bygones]

das [c]data.append("," + rs.getString(1));[/c] macht alles wieder zunichte.
Besser wär

data.append(',');
data.append(rs.getString(1));

ehrlich gesagt hoff ich mal dass der compiler hier einspringt und das für einen optimiert.

@TE:
mich wunderts dass man zuerst einen String macht um dann substring zu rufen....
ansonsten gehören solche zusammenhängenden Konstrukte natürlich auch "räumlich" zu sammen.

 

[faetzminator]

ehrlich gesagt hoff ich mal dass der compiler hier einspringt und das für einen optimiert.

Ein SB wird sowieso erstellt, aber hier muss zusätzlich zum SB [c]data[/c] noch pro Schleifendurchlauf ein weiterer erzeugt werden. Bei meinem Code ist das nicht der Fall. Ich gehe nicht davon aus, dass der Compiler weitere Optimierungen vornimmt.

 

[dngfng]

Habe es jetzt sowieso umgeschrieben da die Daten jetzt aus einer Map kommen.

StringBuffer data = new StringBuffer();

for(Entry<Integer,Integer> x : xs.entrySet()) { 
    data.append(",");
    data.append(x.getKey());
}

if (data.length()>1) {
    data.deleteCharAt(0);
}
String res = data.toString();

Falls euch noch etwas dazu einfällt gebt mir Bescheid.

Ich bin noch immer nicht davon überzeugt das durch die nach gelagert Entfernung des Kommas für den Betroffenen Prozess es einen messbaren Performance voreilt gibt.

 

[bygones]

Ich bin noch immer nicht davon überzeugt das durch die nach gelagert Entfernung des Kommas für den Betroffenen Prozess es einen messbaren Performance voreilt gibt.

Überzeugungen sind im Punkte Performanz Schall und Rauch... wenn du es messen kannst ist es so - Vermutungen sind meist überschätzt.

Wichtiger seh ich die Lesbarkeit - ich hoffe mal dieser Code ist nicht Teil einer komplexeren Methode sondern er ist selbst eine vollständige methode

PS: wenn du nur die Keys haben willst kannst du auch direkt über keySet laufen anstatt entrySet

PPS: Oder nimmst google-collections

return Joiner.on(",").join(xs.keySet());

 

[dngfng]

Danke für den Tipp aber eine externe Libary einbinden ist wirklich Overkill.

 

[mvitz]

Was mir noch aufgefallen ist:

1) Wieso nutzt du StringBuffer? Afaik kann man da heutzutage besser den StringBuilder für nutzen.

2) (Weiß jetzt nicht 100% wie das beim StringBuffer ist) Beim StringBuilder kommt das sogenannte Builder Pattern zum Einsatz, d.h. du könntest das ganze so schreiben:

StringBuilder data = new StringBuilder(); 
for(Entry<Integer,Integer> x : xs.entrySet()) { 
    data.append(",").append(x.getKey());
}
 
if (data.length()>1) {
    data.deleteCharAt(0);
}
String res = data.toString();

 

[bygones]

StringBuffer ist die synchronisierte Version vom StringBuilder - also wenn synchronized nicht relevant ist dann ist StringBuilder vorzuziehen.

und ja dadurch haben sie die gleiche API

 

[faetzminator]

Ich bin noch immer nicht davon überzeugt das durch die nach gelagert Entfernung des Kommas für den Betroffenen Prozess es einen messbaren Performance voreilt gibt.

Nunja, was heisst messbar? Es werden genau [c]x * n + 1[/c] SBs erzeugt, wobei bei deiner ursprünglichen Version [c]x = 1[/c], bei meinem Verbesserungsvorschlag allerdings [c]x = 0[/c]. Natürlich ist die Laufzeit vom gesamten Code immer noch [c]O(n)[/c], aber die Laufzeit pro Item ist (etwas) kleiner.