Folgen Sie dem Video unten, um zu sehen, wie Sie unsere Website als Icon auf Ihrem Homescreen erstellen.
Anmerkung: This feature may not be available in some browsers.
nschum schrieb:An String-Operationen allein wird's doch nicht liegen?
definiert also eine Konstante um und ist wenig performant. Bei exzessiverem Gebrauch sollte man daher die dynamischen StringBuffer nehmen.
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.Strings sind in Java quasi Konstanten, sowas wie
String1="Guten Tag, "+String1;
definiert also eine Konstante um und ist wenig performant. Bei exzessiverem Gebrauch sollte man daher die dynamischen StringBuffer nehmen.
Es ist um einige Größenordnungen langsamer.Ich halte es daher für zweifelhaft, dass das in Java "auf Dauer" langsamer ist.
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.)Es ist um einige Größenordnungen langsamer.
Das lässt sich natürlich noch weiter treiben, mit 1 Mio Durchläufen ist das StringBuilder-Beispiel immer noch in < 1 Sekunde fertig, beim anderen habe ich keine Lust das abzuwarten.Code: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());
angemawad schrieb: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.)
Du meinst, dass bei der ersten Variante dann ein Stringobjekt entstehen sollte, der 1 Mio Zeiger auf (Teil-)Stringsobjekte enthält?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.)
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!".