2011-09-27 13 views
5

¿Existen microensayos publicados que comparen las colecciones mutables e inmutables de Scala entre sí y las colecciones en java.util.concurrent, en entornos con múltiples subprocesos ? Estoy particularmente interesado en casos en los que los lectores superan con creces a los escritores, como el almacenamiento en caché de HashMaps en el código del lado del servidor.Micro-punto de referencia que compara las colecciones mutables e inmutables de Scala con las colecciones java.util.concurrent. *

Las micro-referencias de las colecciones de Clojure también serían aceptables, ya que sus algoritmos son similares a los utilizados en las colecciones persistentes de Scala 2.8.

Escribiré las mías si ya no hay ninguna, pero escribir buenos micro-benchmarks no es trivial.

+0

Creo que es muy poco probable que obtenga un punto de referencia razonable que compare colecciones mutables e inmutables, porque el diseño de la aplicación en sí es diferente. –

+0

@Daniel: actualmente tenemos un código de servidor Java que contiene HashMaps que se leen aproximadamente 1,000,000 de veces para cada escritura. El código usa 'sincronizado', pero los lectores pagan una penalización por todas las lecturas contenidas aunque los datos sean efectivos e inmutables. Pensé que podría usar las colecciones persistentes de functionaljava y bloquear solo cuando reemplazara la colección anterior con la nueva colección "copiada" que contiene el nuevo elemento. – Ralph

+0

Parece una expectativa razonable e ilustra el problema con los puntos de referencia. Si prueba ese tipo de carga, está predisponiendo a la inmutabilidad. Pero tenga en cuenta que, al usar mapas inmutables, debe volver a colocar el mapa cada vez que lo actualice, lo que significa que tendrá que serializar todas las actualizaciones de alguna manera. El mapa en sí mismo podría ser señalado por un elemento volátil, si no te importa lee lo que queda detrás de las escrituras. –

Respuesta

2

hay algunos resultados que comparan los mapas de Java hash, mapas de hash Scala, Java mapas de hash concurrente, Java Mostrar listas concurrentes, matrices paralelas Java y colecciones paralelas Scala aquí (al final del informe técnico):

http://infoscience.epfl.ch/record/165523/files/techrep.pdf

Hay una comparación más detallada de las listas de salto simultáneas y concurrentes de hash de Java mapas aquí (también en el extremo de la parte principal del informe, antes de que el apéndice):

http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf

Estos micro benchmarks se centran en probar el rendimiento de una sola operación. Si va a escribir sus propios puntos de referencia, esto probablemente sea útil: de

http://buytaert.net/files/oopsla07-georges.pdf

+0

¡Muy bien! Gracias. – Ralph

+0

Puede encontrar el código fuente de algunos de los puntos de referencia en el primer documento aquí: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/test/benchmarks/, pero están algo desestructurados. Para la 2da: https://github.com/axel22/Ctries, eche un vistazo en el src/banco. – axel22

+0

Estos son los puntos de referencia detallados sobre las operaciones de cobro de Scala: https://github.com/scalameter/scalameter/tree/master/src/test/scala/org/scalameter/collections – axel22

0

¿Por qué no intentas usar java.util.concurrent.ConcurrentHashMap entonces? de esa manera no tiene que sincronizar, y sus millones de lecturas serán mucho más rápidas (además de las que se escriben).

+1

Creo que es una falacia. Si lee un valor (mutable) de HashMap, actualice ese valor, intente poner de nuevo, debe sincronizar la operación. No estoy seguro si puedes hacerlo con 'replace'. – Ralph

+0

Otra opción sería usar el STM de Clojure (puede usarlo desde Java). Aunque no estoy seguro de cómo lo usarías con un HashMap ... – Chochos

Cuestiones relacionadas