stringbuilder java

Penalización de rendimiento de String.intern()

Question

Muchas personas hablan sobre las ventajas de rendimiento de String.intern (), pero en realidad estoy más interesado en cuál puede ser la penalización de rendimiento.

Mis principales preocupaciones son:

• Costo de búsqueda : el tiempo que toma el interno () para determinar si la cadena interna existe en el grupo de constantes. ¿Cómo escala ese costo la escala con el número de cadenas en ese grupo?
• Sincronización : obviamente, el conjunto constante es compartido por toda la JVM. ¿Cómo se comporta ese grupo cuando se llama una y otra vez a intern () desde varios subprocesos? ¿Cuánto bloqueo realiza? ¿Cómo se escala el rendimiento con contención?

Me preocupan todas estas cosas porque actualmente estoy trabajando en una aplicación financiera que tiene el problema de usar demasiada memoria debido a las cadenas duplicadas. Algunas cadenas parecen básicamente valores enumerados y solo pueden tener un número limitado de valores potenciales (como los nombres de moneda ("USD", "EUR")) en más de un millón de copias. String.intern () parece una obviedad en este caso, pero estoy preocupado por la sobrecarga de sincronización de llamar a intern () cada vez que almaceno una moneda en alguna parte.

Además de eso, algunos otros tipos de cadenas pueden tener millones de valores diferentes, pero todavía tienen decenas de miles de copias de cada uno (como los códigos ISIN). Para estos, me preocupa que el internar un millón de cadenas ralentizaría básicamente el método interno () tanto como para empantanar mi aplicación.

Answer 1

El siguiente micro benchmark sugiere usar una enumeración que ofrece una mejora de rendimiento de alrededor de diez veces (se aplican las advertencias de micro benchmark habituales) de la siguiente manera:

public class Test {
   private enum E {
      E1;
      private static final Map<String, E> named = new HashMap<String, E>();
      static {
         for (E e : E.values()) {
            named.put( e.name(), e );
         }
      }

      private static E get(String s) {
         return named.get( s );
      }
   }

   public static void main(String... strings) {
      E e = E.get( "E1" ); // ensure map is initialised

      long start = System.nanoTime();
      testMap( 10000000 );
      long end = System.nanoTime();

      System.out.println( 1E-9 * (end - start) );
   }

   private static void testIntern(int num) {
      for (int i = 0; i < num; i++) {
         String s = "E1".intern();
      }
   }

   private static void testMap(int num) {
      for (int i = 0; i < num; i++) {
         E e = E.get( "E1" );
      }
   }
}

Resultados (10 millones de iteraciones): testIntern () - 0.8 seconds testMap () - 0.06 segundos

Por supuesto, YMMV, pero las enumeraciones ofrecen tantos beneficios sobre las cadenas ... la seguridad de tipo sobre otras cadenas aleatorias, la capacidad de agregar métodos, etc. parece ser la mejor manera de hacerlo.

Answer 2

He encontrado que es mejor usar una tabla de hash fastutil y hacer mi propia práctica en lugar de volver a utilizar String.intern() . Usar mi propia tabla hash significa que puedo tomar mis propias decisiones sobre la concurrencia, y no estoy compitiendo por el espacio PermGen.

Hice esto porque estaba trabajando en un problema que tenía, por así decirlo, millones de cadenas, muchas idénticas, y quería (a) reducir la huella y (b) permitir la comparación por identidad. Para mi problema, las cosas fueron mejores con la internación que sin ella, utilizando mi String.intern() no String.intern() .

YMMV.

Answer 3

Hice un poco de benchmarking yo mismo. Para la parte del costo de búsqueda, he decidido comparar String.intern () con ConcurrentHashMap.putIfAbsent (s, s). Básicamente, esos dos métodos hacen las mismas cosas, excepto que String.intern () es un método nativo que almacena y lee desde un SymbolTable que se administra directamente en la JVM, y ConcurrentHashMap.putIfAbsent () es solo un método de instancia normal.

Puede encontrar el código de referencia en github gist (por falta de un lugar mejor para ponerlo). También puede encontrar las opciones que utilicé al iniciar la JVM (para verificar que la referencia no esté sesgada) en los comentarios en la parte superior del archivo fuente.

De todos modos aquí están los resultados:

Costo de búsqueda (rosca simple)

Leyenda

• recuento : el número de cadenas distintas que estamos tratando de agrupar
• interno inicial : el tiempo en ms que se tardó en insertar todas las cadenas en el grupo de cadenas
• buscar la misma cadena : el tiempo en ms que se tardó en buscar cada una de las cadenas nuevamente desde el grupo, usando exactamente la misma instancia que se ingresó previamente en el grupo
• cadena de búsqueda igual : el tiempo en ms que tardó en buscar cada una de las cadenas desde el grupo, pero utilizando una instancia diferente

String.intern ()

count       initial intern   lookup same string  lookup equal string
1''000''000            40206                34698                35000
  400''000             5198                 4481                 4477
  200''000              955                  828                  803
  100''000              234                  215                  220
   80''000              110                   94                   99
   40''000               52                   30                   32
   20''000               20                   10                   13
   10''000                7                    5                    7

ConcurrentHashMap.putIfAbsent ()

count       initial intern   lookup same string  lookup equal string
1''000''000              411                  246                  309
  800''000              352                  194                  229
  400''000              162                   95                  114
  200''000               78                   50                   55
  100''000               41                   28                   28
   80''000               31                   23                   22
   40''000               20                   14                   16
   20''000               12                    6                    7
   10''000                9                    5                    3

La conclusión del costo de búsqueda: String.intern () es sorprendentemente caro de llamar. Se escala extremadamente mal, en algo de O (n) donde n es el número de cadenas en el conjunto. Cuando crece el número de cadenas en el conjunto, la cantidad de tiempo para buscar una cadena del grupo crece mucho más (0,7 microsegundos por búsqueda con 10,000 cadenas, 40 microsegundos por búsqueda con 1 000000 cadenas).

ConcurrentHashMap escala como se espera, el número de cadenas en el conjunto no tiene impacto en la velocidad de la búsqueda.

Basado en este experimento, le sugiero que evite usar String.intern () si va a internar más de unas cuantas cuerdas.

Answer 4

Recientemente escribí un artículo sobre la implementación de String.intern () en Java 6, 7 y 8: java-performance.info/string-intern-in-java-6-7-8 .

Existe un parámetro -XX: StringTableSize JVM, que le permitirá hacer que String.intern sea extremadamente útil en Java7 +. Por lo tanto, desafortunadamente tengo que decir que esta pregunta actualmente está dando información engañosa a los lectores.