nschum schrieb:
.Das gleiche gibt es auch in Objective-C und da ist es ein Gerücht, dass dies ein schlechteres Laufzeitverhalten hat. Du hast als Overhead zwar die Objektallozierung, dafür sparst du Speicher und Kopierzeit. Da nämlich alle beteiligten Partner Konstanten sind, lässt sich das kacheln. Man muss nur ein paar Pointer auf die Backends hinbritzeln.
Es ist um einige Größenordnungen langsamer.
java.util.Random rand = new java.util.Random();
String test = "";
StringBuilder test2 = new StringBuilder(test);
for( int i = 0; i<10000; i++) {
//Zeitangabe, wenn auskommentiert:
//test += String.valueOf(rand.nextInt()); // ca. 20 Sekunden
//test2.append(String.valueOf(rand.nextInt())); // ca. 0 Sekunden
}
if(test2.length() > 0) test = test2.toString();
System.out.print(test.length());test = "foobar1234567890123456789012345678901234567890";
test += String.valueOf(rand.nextInt());
Oha. So hab ich das doch gar nicht gemeint. Ich bin auch ein Gegner von „Java ist kack lahm“, aber afaik sind C und D doch meist etwas schneller (wobei man die aber auch langsamer bekommt als Java, wenn man nur schön scheiße programmiert *g*). Bei den meisten Anwendungen wird man aber keinen Unterschied spüren.Also sooo langsam ist Java nun auch nicht. Es gibt nur viele Java-Programmierer, die keine Ahnung haben, wie man Java programmiert
Schlecht implementiert, das darf nicht passieren. Beide Varianten müssen einen String erzeugen, beide "verschmelzen". append muss dazu die einzelnen Bytes kopieren, da es veränderlich ist und sich mit dem Werteobjekt keinen Speicher teilen darf. Das neue Objekt muss einfach zwei Zeiger in Kacheln kopieren. (Bei einer anständigen Implementierung.)
angemawad schrieb:
Du meinst, dass bei der ersten Variante dann ein Stringobjekt entstehen sollte, der 1 Mio Zeiger auf (Teil-)Stringsobjekte enthält?
Die Implementierung und ihr Laufzeitverhalten haben wir ja für einen Fall gesehen. Nein, ich kenne die Java-Implementierung nicht, sehe aber das Laufzeitverhalten.Nun so weit reichen eine Kenntnisse nicht! Ich kenne den Sourcecode von Java nicht
Wie Du merkst gibt es unterschiedliche Herangehensweisen an die Dinge, mit unterschiedlichen Vor- und Nachteilen und man kann Dinge anders lösen als in Objective-C!
Hier haben wir definitiv einen Nachteil, wenn man Strings so verwendet wie man es aus anderen Sprachen kennt. Da aber ein Großteil der Stringnutzung ein stumpfes Ausgeben von impliziten Konstanten (Literalen) darstellt und für Stringmanipulationen ein Extraobjekt ( der Stringbuffer) bereitsteht ist das überhaupt kein Problem. Es gilt halt wie immer: "know your tools" und "nur weil etwas anders ist muß es nicht schlechter sein!".