Ich erwäge, eine RFE (Anfrage für die Erweiterung) an die Oracle Bug Database zu senden, die die String-Verkettungsleistung erheblich erhöhen soll. Aber bevor ich das tue, möchte ich gerne die Kommentare der Experten hören, ob das Sinn macht.
Die Idee basiert auf der Tatsache, dass das vorhandene String.concat (String) auf zwei Strings doppelt so schnell arbeitet wie StringBuilder. Das Problem besteht darin, dass es keine Methode gibt, 3 oder mehr Zeichenfolgen zu verketten. Externe Methoden können dies nicht, da String.concat einen privaten Paketkonstruktor String(int offset, int count, char[] value) verwendet, der das char-Array nicht kopiert, sondern direkt verwendet. Dies gewährleistet eine hohe String.concat-Leistung. Im selben Paket kann StringBuilder diesen Konstruktor immer noch nicht verwenden, da dann das char-Array des Strings für Änderungen offen gelegt wird.
Ich empfehle, die folgenden Methoden zu String
hinzuzufügen %Vor%Hinweis: Diese Art der Überladung wird aus Effizienzgründen in EnumSet.of verwendet.
Dies ist die Implementierung einer der Methoden, andere arbeiten auf die gleiche Weise
%Vor%Nachdem diese Methoden zu String, Java-Compiler für
hinzugefügt wurden %Vor%kann effizient bauen
%Vor%statt aktuell ineffizient
%Vor%UPDATE Leistungstest. Ich lief es auf meinem Notebook Intel Celeron 925, Verkettung von 3 Strings, meine String2-Klasse emuliert genau, wie es in echten java.lang.String wäre. String-Längen werden so gewählt, dass StringBuilder unter den ungünstigsten Bedingungen platziert werden kann, dh wenn es seine interne Pufferkapazität bei jedem Append erweitern muss, während concat immer nur char [] erstellt.
%Vor%Bei 1.000.000 Iterationen sind die Ergebnisse:
%Vor% Tatsache ist, dass die Anwendungsfälle, bei denen die Ausführung eines einzelnen String-Verkettungsausdrucks eine Rolle spielt, nicht so häufig vorkommen. In den meisten Fällen, in denen die Performance durch eine String-Verkettung gebunden ist, geschieht dies in einer Schleife, wobei das Endprodukt Schritt für Schritt aufgebaut wird, und in diesem Kontext ist die änderbare StringBuilder ein klarer Gewinner. Aus diesem Grund sehe ich für einen Vorschlag, der eine Minderheitsbeteiligung durch Eingriffe in die fundamentale String -Klasse optimiert, nicht viel Perspektive. Was den Leistungsvergleich anbelangt, hat Ihr Ansatz jedoch einen entscheidenden Vorteil:
Ergebnis:
%Vor%Wenn Sie möchten, dass sie Sie ernst nehmen, müssen Sie die harte Arbeit der vollständigen Implementierung, des Testens und des gründlichen Benchmarking Ihrer vorgeschlagenen Änderung leisten. Und eine vollständige Implementierung würde die Änderungen am Java-Compiler beinhalten, um Bytecodes zur Verwendung Ihrer Methoden zu senden.
Schreiben Sie die Ergebnisse auf und senden Sie die Codeänderungen als Patch an OpenJDK 7 oder 8.
Mein Eindruck ist, dass die Java-Entwickler nicht über die Ressourcen verfügen, spekulative Ideen für Optimierungen wie diese auszuprobieren. Ein RFE ohne Benchmarking-Ergebnisse und Code-Patches wird wahrscheinlich keine Aufmerksamkeit erhalten ...
Es ist immer in Ordnung, sie zu fragen, keine Sorge.
Ich hätte nicht so viele überladene Versionen. In EnumSet kann das Speichern erheblich sein; nicht so in String.
Tatsächlich denke ich, dass eine statische Methode, die eine beliebige Anzahl von Argumenten erlaubt, besser ist
%Vor%, da die Anzahl der Argumente zur Kompilierzeit unbekannt sein kann.
Tags und Links string java string-concatenation