5
Esistono microsupporti di riferimento pubblicati che confrontano le collezioni mutabili e immutabili Scala con le altre e le raccolte in java.util.concurrent, in ambienti con più thread ? Sono particolarmente interessato ai casi in cui i lettori superano di gran lunga gli scrittori, ad esempio la memorizzazione nella cache di HashMaps nel codice lato server.Micro benchmark per il confronto di collezioni mutabili e immutabili Scala con java.util.concurrent * collezioni
I micro-benchmark delle collezioni Clojure sarebbero anche accettabili, in quanto i loro algoritmi sono simili a quelli utilizzati nelle collezioni persistenti di Scala 2.8.
Scriverò da solo se non ce ne sono già state fatte, ma scrivere buoni micro-benchmark non è banale.
Penso che sia estremamente improbabile ottenere un benchmark ragionevole che paragoni collezioni mutevoli e immutabili, perché il design dell'applicazione stessa è diverso. –
@Daniel: al momento disponiamo di un codice server Java che contiene HashMaps che vengono letti circa 1.000.000 di volte per ogni scrittura. Il codice usa 'synchronized', ma i lettori pagano una penalità per tutte quelle letture contese anche se i dati sono effettivamente immutabili. Ho pensato che potrei essere in grado di utilizzare le collezioni persistenti da functionaljava e bloccare solo quando si sostituisce la vecchia raccolta con la nuova raccolta "copiata" contenente il nuovo elemento. – Ralph
Sembra un'aspettativa ragionevole e illustra il problema con i benchmark. Se testate questo tipo di carico, state influenzando l'immutabilità. Nota che, usando mappe immutabili, devi _replace_ la mappa ogni volta che aggiorni, il che significa che dovrai serializzare tutti gli aggiornamenti in qualche modo. La mappa stessa potrebbe essere indicata da un volatile, se non ti dispiace leggere le scritte in ritardo. –