Eines Tages habe ich einem meiner Freunde über eine bestimmte Telerik-Kontrolle geschimpft. Ich habe ihm gesagt, dass es einige Sekunden gedauert hat, um einen Kontrollbaum zu generieren, und nach dem Profiling habe ich herausgefunden, dass es eine String-Verkettung in einer Schleife statt eines StringBuilders verwendet. Nach dem Umschreiben funktionierte es fast augenblicklich.
Mein Freund hörte das und schien überrascht zu sein, dass der C # -Compiler diese Umwandlung nicht wie der Java-Compiler automatisch ausgeführt hat. Wenn ich viele Antworten von Eric Lippert lese, merke ich, dass dieses Feature es nicht geschafft hat, weil es nicht als angemessen genug angesehen wurde. Aber wenn die Kosten hypothetisch klein wären, um sie umzusetzen, welche Gründe würden das verhindern?
Ich stelle fest, dass dies ein exaktes Duplikat von
istWarum ist String.Concat nicht für StringBuilder.Append optimiert? ?
also sollte das wohl geschlossen sein.
Aber wenn hypothetisch die Kosten gering wären, um sie umzusetzen, welche Gründe würden es davon abhalten?
Es klingt, als würdest du ein bisschen Tautologie vorschlagen: Wenn es keinen Grund gibt, X nicht zu machen, gibt es dann einen Grund, X nicht zu machen? Nein.
Ich sehe wenig Wert darin, die Antworten auf hypothetische, kontrafaktische Fragen zu kennen. Vielleicht eine bessere Frage zu stellen wäre eine Frage über die reale Welt :
Gibt es Programmiersprachen, die diese Optimierung verwenden?
Ja. In JScript.NET erkennen wir String-Verkettungen in Schleifen und der Compiler verwandelt sie in Aufrufe eines String-Builders.
Dies könnte dann gefolgt werden mit:
Was sind einige der Unterschiede zwischen JScript .NET und C #, die die Optimierung in der einen, aber nicht in der anderen Sprache rechtfertigen?
Eine Kernannahme von JScript.NET ist, dass Programmierer meist JavaScript-Programmierer sind und viele von ihnen bereits Bibliotheken erstellt haben, die in jeder Implementierung von ECMAScript laufen müssen. Diese Programmierer kennen das .NET-Framework möglicherweise nicht gut, und selbst wenn sie das tun, können sie StringBuilder möglicherweise nicht verwenden, ohne ihren Bibliothekscode nicht portierbar zu machen. Es ist auch vernünftig anzunehmen, dass es sich bei JavaScript-Programmierern entweder um Anfänger-Programmierer oder um Programmierer handelt, die über ihr Fachgebiet zum Programmieren gekommen sind und nicht über ein Informatikstudium.
C # -Programmierer kennen das .NET-Framework sehr viel besser, schreiben Bibliotheken, die mit dem Framework arbeiten, und erfahrene Programmierer, die verstehen, warum die Schleifen-String-Verkettung O ist (n 2 ) in der naiven Umsetzung. Sie brauchen diese Optimierung , die vom Compiler generiert wird, weniger, weil sie es selbst tun können, wenn sie es für notwendig halten.
Kurz gesagt: Bei den Compiler-Funktionen geht es darum, unser Budget auszugeben, um dem Kunden einen Mehrwert zu bieten. Sie erhalten mehr "bang for buck", indem Sie das Feature zu JScript.NET hinzufügen, anstatt es zu C # hinzuzufügen.
Der C # -Compiler ist besser als das.
a + b + c wird nach String.Concat(a, b, c) kompiliert, was schneller ist als StringBuilder .
"a" + "b" wird direkt in "ab" kompiliert (nützlich für mehrzeilige Literale).
Die einzige Stelle, an der StringBuilder verwendet wird, ist die wiederholte Verknüpfung innerhalb einer Schleife. der Compiler kann das nicht einfach optimieren.
Tags und Links string c# compiler-optimization stringbuilder