Die effizienteste anfängliche Kapazitätsgröße für StringBuilder?

Question

Ich schreibe viele Sachen, um Bursts einzuloggen und den Datenpfad zu optimieren. Ich baue den Log-Text mit StringBuilder. Was wäre die effizienteste Anfangskapazität, Speicherverwaltung, also würde es unabhängig von JVM gut funktionieren? Ziel ist es, eine Umverteilung fast immer zu vermeiden, die durch eine Anfangskapazität von etwa 80-100 gedeckt werden sollte. Aber ich möchte auch so wenig Bytes wie möglich verschwenden, da die StringBuilder-Instanz im Puffer hängen bleiben kann und verschwendet Bytes auftauchen.

Ich weiß, dies hängt von JVM ab, aber es sollte einen Wert geben, der kleinste Bytes verschwenden würde, unabhängig von der JVM, eine Art "kleinster gemeinsamer Nenner". Ich verwende derzeit 128-16, wobei die 128 eine nette runde Zahl ist, und die Subtraktion ist für den Overhead der Zuweisung. Dies könnte auch als "vorzeitige Optimierung" betrachtet werden, aber da es sich bei der Antwort um eine "Daumenregel" handelt, weiß man, dass sie auch in Zukunft nützlich sein wird.

Ich erwarte nicht "meine beste Vermutung" Antworten (meine eigene Antwort oben ist schon das), ich hoffe, jemand hat dies bereits recherchiert und kann eine wissensbasierte Antwort teilen.

Answer 1

Nun, ich endete das Testen selbst kurz, und dann testen Sie einige mehr nach Kommentaren, um diese bearbeitete Antwort zu erhalten.

Mit JDK 1.7.0_07 und Test-App Reporting VM-Namen "Java HotSpot (TM) 64-Bit Server VM", Granularität der StringBuilder Speichernutzung ist 4 Zeichen, bei noch 4 Zeichen zu erhöhen.

Antwort: ein beliebiges Vielfaches von 4 ist gleich gut Kapazität für StringBuilder von Speicherzuweisung Sicht, zumindest auf dieser 64-Bit-JVM.

Getestet durch Erstellen von 1000000 StringBuilder-Objekten mit unterschiedlichen Anfangskapazitäten, in verschiedenen Testprogrammausführungen (um den gleichen anfänglichen Heap-Status zu haben) und Ausdrucken von ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getUsed() davor und danach.

Drucken von Heap-Größen auch bestätigt, die tatsächlich aus Heap für jeden StringBuilder Puffer ist ein gleichmäßiges Vielfaches von 8 Bytes zugewiesen, wie erwartet, da Java-Zeichen 2 Byte lang ist.Mit anderen Worten, das Zuweisen von 1000000 Instanzen mit der Anfangskapazität 1..4 benötigt ungefähr 8 Megabyte weniger Speicher (8 Bytes pro Instanz) als das Zuweisen der gleichen Anzahl von Instanzen mit der Anfangskapazität 5 ... 8.

Answer 2

Versuchen Sie nicht, in diesem Fall intelligent zu sein.

Ich verwende derzeit 128-16, wo die 128 eine nette runde Zahl ist, und Subtraktion ist für die Zuweisung Overhead.

In Java basiert dies auf völlig willkürlichen Annahmen über das Innenleben einer JVM. Java ist nicht C. Byte-Ausrichtung und dergleichen sind absolut nicht ein Problem, das der Programmierer ausprobieren kann oder sollte versuchen.

Wenn Sie die (mögliche) maximale Länge Ihrer Zeichenfolgen kennen, können Sie diese für die Anfangsgröße verwenden. Ansonsten sind Optimierungsversuche vergebens.

Wenn Sie wirklich wissen, dass große Mengen an Ihren StringBuilder s für sehr lange Zeiträume um sein (was nicht ganz das Konzept der Protokollierung passen), und Sie wirklich das Bedürfnis verspüren, zu versuchen, die JVM zu überzeugen Um einige Bytes Heapspeicher zu sparen, können Sie versuchen, trimToSize() zu verwenden, nachdem die Zeichenfolge vollständig erstellt wurde. Aber solange Ihre Strings keine Megabytes verschwenden, sollten Sie sich wirklich auf andere Probleme in Ihrer Anwendung konzentrieren.