String vs. StringBuffer!!!

Griffin

Dazu sollte man vielleicht noch erwähnen, dass StringBuilder erst ab Java 5.0 zur Verfügung steht!

Es gibt nur ein wahres Java.

(Schmarrn, hast natürlich Recht )

Real

Griffin schrieb:

Dazu sollte man vielleicht noch erwähnen, dass StringBuilder erst ab Java 5.0 zur Verfügung steht!

Jup. StringBuilder ist glaube ich nicht synchronisiert und somit etwas schneller als StringBuffer.

Liebe Grüße
Reality

destruct0r

Aber auch wenn man mit einer Version < (1.)5.0 arbeitet/arbeiten muss kann man die Performance verbessern, dadurch dass man den Performancevorteil ausnutzt, der entsteht, wenn ein Monitor beim Betreten einer synchronized Methode nicht erneut befragt werden muss. ("reentering") Nachzulesen unter [1].
Sprich:

StringBuffer sb = new StringBuffer();
for (int i = 0; i < 1000; i++) {
  sb.append(i);
}

//Folgender Code ist (angeblich) schneller.
sb = new StringBuffer();
synchronized (sb) {
  for (int i = 0; i < 1000; i++) {
    sb.append(i);
  }
}

Erwähnen sollte ich noch, dass ich den Effekt bisher noch nicht selbst getestet und somit verifiziert habe - aber ich denke mal, dass das schon stimmen wird

[1] http://www.galileocomputing.de/openbook/javainsel3/javainsel_090009.htm#Rxxjavainsel_090009473MonitoresindreentrantgutfurdieGeschwindigkeit

Real

Krass, aber bei Methoden soll es das Gegenteil bewirken, nämlich Perfomanceverlust. Aber bei Multithreading lässt sich eine synchronized Methode kaum vermeiden.

Liebe Grüße
Real

Real schrieb:

Aber bei Multithreading lässt sich eine synchronized Methode kaum vermeiden.

Das sehe ich nicht so. Wenn kein anderer Thread auf meinem StringBuilder was macht, muss er auch nicht gelockt werden.

destruct0r

aber bei Methoden soll es das Gegenteil bewirken, nämlich Perfomanceverlust

Das verstehe ich jetzt nicht ganz - was meinst du damit?

Real

destruct0r schrieb:

aber bei Methoden soll es das Gegenteil bewirken, nämlich Perfomanceverlust
Das verstehe ich jetzt nicht ganz - was meinst du damit?

Wenn in einer Klasse mehrere Methoden auf eine Variable zugreifen und das multithreaded geschieht, muss man die Methoden synchronisieren, die auf dieselbe Variable zugreifen. Damit bewrikt man, dass nur eine Methode gleichzeitig auf die Variable zugreift.

Wenn man jedoch unnötig Methoden synchronisiert (z.B. wenn keine andere Methode auf dieselbe Variable zugreift), dann geht es mit der Perfomance nach unten.

Liebe Grüße
Real

interpreter

Real schrieb:

destruct0r schrieb:
aber bei Methoden soll es das Gegenteil bewirken, nämlich Perfomanceverlust
Das verstehe ich jetzt nicht ganz - was meinst du damit?
Wenn in einer Klasse mehrere Methoden auf eine Variable zugreifen und das multithreaded geschieht, muss man die Methoden synchronisieren, die auf dieselbe Variable zugreifen.

Man MUSS garnichts, und wenn die Threads nur lesend zugreifen macht die Synchronisierung auch keinen Sinn.

Real

Ja, natürlich nur, wenn man die Variable verändert.

Liebe Grüße
Reality

interpreter schrieb:

Man MUSS garnichts, und wenn die Threads nur lesend zugreifen macht die Synchronisierung auch keinen Sinn.

Leider auch nicht immer richtig.

Wenn ich eine komplexe Datenstruktur unsynchronisiert auslese, kann sie sich während dem auslesen verändern.
Das kann durchaus auch ungewünscht sein.

z.B. möchte ich eine Kopie erstellen, aber am Ende ist sie weder vom alten Zustand eine Kopie noch vom neuen, sondern hat von beiden etwas.

destruct0r

Wenn in einer Klasse mehrere Methoden auf eine Variable zugreifen und das multithreaded geschieht, muss man die Methoden synchronisieren, die auf dieselbe Variable zugreifen. Damit bewrikt man, dass nur eine Methode gleichzeitig auf die Variable zugreift.

Wenn man jedoch unnötig Methoden synchronisiert (z.B. wenn keine andere Methode auf dieselbe Variable zugreift), dann geht es mit der Perfomance nach unten.

Das hat jettz aber nichts damit zu tun, was ich gepostet habe.

Ja - wenn man eine Methode synchronosiert, dann wird die Ausführung etwas langsamer - ich habe jetzt aber beschrieben, wie man diesen Effekt eben in gewissen Situationen 'aufheben' kann.

Sgt. Nukem

Optimizer schrieb:

interpreter schrieb:

Man MUSS garnichts, und wenn die Threads nur lesend zugreifen macht die Synchronisierung auch keinen Sinn.

Leider auch nicht immer richtig.

Wenn ich eine komplexe Datenstruktur unsynchronisiert auslese, kann sie sich während dem auslesen verändern.
Das kann durchaus auch ungewünscht sein.

z.B. möchte ich eine Kopie erstellen, aber am Ende ist sie weder vom alten Zustand eine Kopie noch vom neuen, sondern hat von beiden etwas.

Öhhh... aber dazu müsste man ja SCHREIBEND zugreifen...?!?

Wenn ich eine Kopie von etwas erstelle? Dazu muss ich nur dieses etwas auslesen.

Sgt. Nukem

Optimizer schrieb:

Wenn ich eine Kopie von etwas erstelle? Dazu muss ich nur dieses etwas auslesen.

Aber wenn die Kopie keine Kopie ist (weil zwischendurch der Zustand geändert wurde) wie Du sagst - dann wurde dort irgendwann dazwischen mal SCHREIBEND zugegriffen...

Ja, von einem anderem Thread aus. Deshalb ist es evtl. auch sinnvoll, das Auslesen zu synchronisieren. Darum geht es ja.

Sgt. Nukem

Optimizer schrieb:

Ja, von einem anderem Thread aus. Deshalb ist es evtl. auch sinnvoll, das Auslesen zu synchronisieren. Darum geht es ja.

Ich glaube wir reden aneinander vorbei...

Ich zitiere Dich nochmal...

Optimizer schrieb:

interpreter schrieb:

Man MUSS garnichts, und wenn die Threads nur lesend zugreifen macht die Synchronisierung auch keinen Sinn.

Leider auch nicht immer richtig.

Also dann... jetzt erklär' mal...!

ok, jetzt versteh ich... wenn alle Threads nur lesend zugreifen, geht es natürlich ohne sync.

blablabla

btw. noch ein Grund mehr für immutable classes.

interpreter

Optimizer schrieb:

ok, jetzt versteh ich... wenn alle Threads nur lesend zugreifen, geht es natürlich ohne sync.

Nichts anderes habe ich geschrieben.
Erst denken, dann posten.

Sgt. Nukem

Quatsch!
interpreter meinte in Wirklichkeit, wenn 7 von 10 Threads lesend, und 2 schreibend zugreifen... *SCNR*