Qual è la libreria di raccolte Java più efficiente? [chiuso]

Qual è la libreria di raccolte Java più efficiente?

Alcuni anni fa, ho fatto un sacco di Java e ha avuto l'impressione di allora che trove è la migliore (più efficiente) implementazione Java collezioni. Ma quando ho letto le risposte alla domanda " La maggior parte delle librerie Java utili gratis? " Ho notato che tesoro è appena accennato. Quindi quale libreria di raccolte Java è la migliore ora?

AGGIORNAMENTO: Per chiarire, desidero principalmente sapere quale libreria utilizzare quando devo archiviare milioni di voci in una tabella hash ecc. (Ho bisogno di un piccolo runtime e footprint di memoria).

Dall'ispezione, sembra che Trove sia solo una libreria di raccolte per tipi primitivi - non è come se intendesse aggiungere molta funzionalità rispetto alle normali raccolte in JDK.

Personalmente (e sono di parte) adoro Guava (incluso l'ex progetto Google Java Collections). Rende varie attività (comprese le raccolte) molto più semplici, in un modo almeno ragionevolmente efficiente. Dato che le operazioni di raccolta raramente costituiscono un collo di bottiglia nel mio codice (nella mia esperienza), questo è "migliore" di un'API di raccolta che può essere più efficiente ma non rende il mio codice leggibile.

Dato che la sovrapposizione tra Trove e Guava è praticamente nulla, forse potresti chiarire cosa stai effettivamente cercando da una biblioteca di collezioni.

La domanda è (ora) sulla memorizzazione di molti dati, che possono essere rappresentati usando tipi primitivi come int, in una Mappa. Alcune delle risposte qui sono molto fuorvianti secondo me. Vediamo perché.

Ho modificato il benchmark da trove a misurare sia il tempo di esecuzione che il consumo di memoria. Ho anche aggiunto PCJ a questo benchmark, che è un'altra libreria di raccolte per tipi primitivi (la uso ampiamente). Il benchmark "ufficiale" non confronta IntIntMaps con Java Collection Map<Integer, Integer>, probabilmente l'archiviazione Integerse l'archiviazione intsnon sono le stesse dal punto di vista tecnico. Ma a un utente potrebbe non interessare questo dettaglio tecnico, desidera archiviare i dati rappresentabili in modo intsefficiente.

Innanzitutto la parte pertinente del codice:

new Operation() {

     private long usedMem() {
        System.gc();
        return Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
     }

     // trove
     public void ours() {
        long mem = usedMem();
        TIntIntHashMap ours = new TIntIntHashMap(SET_SIZE);
        for ( int i = dataset.size(); i-- > 0; ) {
           ours.put(i, i);
        }
        mem = usedMem() - mem;
        System.err.println("trove " + mem + " bytes");
        ours.clear();
     }

     public void pcj() {
        long mem = usedMem();
        IntKeyIntMap map = new IntKeyIntOpenHashMap(SET_SIZE);
        for ( int i = dataset.size(); i-- > 0; ) {
           map.put(i, i);
        }
        mem = usedMem() - mem;
        System.err.println("pcj " + mem + " bytes");
        map.clear();
     }

     // java collections
     public void theirs() {
        long mem = usedMem();
        Map<Integer, Integer> map = new HashMap<Integer, Integer>(SET_SIZE);
        for ( int i = dataset.size(); i-- > 0; ) {
           map.put(i, i);
        }
        mem = usedMem() - mem;
        System.err.println("java " + mem + " bytes");
        map.clear();
     }

Presumo che i dati siano primitivi ints, il che sembra sano. Ma ciò implica una penalità di runtime per java util, a causa del boxing automatico, che non è necessario per i framework di raccolte primitive.

I risultati di runtime (senza gc()chiamate, ovviamente) su WinXP, jdk1.6.0_10:

                      100000 operazioni put 100000 contiene operazioni 
raccolte java 1938 ms 203 ms
trove 234 ms 125 ms
pcj 516 ms 94 ms

Sebbene ciò possa già sembrare drastico, non è questo il motivo per utilizzare un tale framework.

Il motivo è la prestazione di memoria. I risultati per una mappa contenente 100000 intvoci:

Le raccolte java oscilla tra 6644536 e 7168840 byte
trove 1853296 byte
pcj 1866112 byte

Le raccolte Java richiedono una memoria tre volte superiore rispetto ai framework di raccolta primitivi. Vale a dire che è possibile conservare tre volte più dati in memoria, senza ricorrere all'IO del disco che riduce le prestazioni di runtime per grandezza. E questo conta. Leggi l'alta scalabilità per scoprire perché.

Nella mia esperienza, l'elevato consumo di memoria è il più grande problema di prestazioni con Java, che ovviamente comporta anche peggiori prestazioni di runtime. I framework di raccolta primitivi possono davvero aiutare qui.

Quindi: No, java.util non è la risposta. E "aggiungere funzionalità" alle raccolte Java non è il punto quando si chiede efficienza. Anche le moderne collezioni JDK non "superano nemmeno le collezioni specializzate Trove".

Disclaimer: il benchmark qui è tutt'altro che completo, né è perfetto. È pensato per portare a casa il punto, che ho sperimentato in molti progetti. Le raccolte primitive sono abbastanza utili per tollerare l'API fishy - se lavori con molti dati.

So che questo è un vecchio post e ci sono un sacco di risposte qui. Ma le risposte sopra sono superficiali e troppo semplificate in termini di suggerimento di una biblioteca. Non esiste una libreria che vada bene attraverso i vari benchmark presentati qui. L'unica conclusione che traggo è se ti preoccupi delle prestazioni e della memoria e hai a che fare con tipi primitivi, vale la pena guardare le alternative non jdk.

Ecco un'analisi più solida, in termini di meccanica di riferimento e librerie coperte. Questo è un thread nella lista degli sviluppatori mahout.

Le biblioteche coperte sono

• HPPC
• Raccolta
• FastUtil
• Mahout (Colt)
• Collezioni Java

Aggiornamento giugno 2015 : sfortunatamente, i benchmark originali non sono più disponibili e inoltre sono un po 'obsoleti. Ecco alcuni benchmark abbastanza recenti (gennaio 2015) fatti da qualcun altro. Non è così completo né ha gli strumenti esplorativi interattivi come il link originale.

Come hanno notato altri commentatori, la definizione di "efficiente" lancia una vasta rete. Tuttavia nessuno ha ancora menzionato la libreria Javolution .

Alcuni dei punti salienti:

• Le classi Javolution sono veloci, molto veloci (ad es. Inserimento / cancellazione del testo in O [Log (n)] invece di O [n] per StringBuffer / StringBuilder standard).
• Tutte le classi Javolution sono conformi in tempo reale e hanno un comportamento altamente deterministico (nel range dei microsecondi). Inoltre (a differenza della libreria standard), Javolution è sicuro RTSJ (nessun scontro di memoria o perdita di memoria se utilizzato con l'estensione Java Real-Time).
• Le classi di raccolta in tempo reale di Javolution (mappa, elenco, tabella e set) possono essere utilizzate al posto della maggior parte delle classi di raccolta standard e forniscono funzionalità aggiuntive.
• Le raccolte Javolution forniscono garanzie di concorrenza per facilitare l'implementazione di algoritmi paralleli.

La distribuzione Javolution include una suite di benchmark in modo da poter vedere come si sovrappongono ad altre librerie / raccolte incorporate.

Alcune librerie di raccolta da considerare:

• Collezioni Java in java.util
• Raccolta
• Biblioteca di Google Collections
• Collezioni Apache Commons
• Lib su larga scala di Cliff Click
• Le raccolte lib di Doug Lea - non più supportate e per lo più ricostruite in JDK

Vorrei prima di tutto raggiungere la biblioteca della collezione JDK. Copre le cose più comuni che devi fare ed è ovviamente già a tua disposizione.

Google Collections è probabilmente la migliore libreria di alta qualità al di fuori di JDK. È molto usato e ben supportato.

Le collezioni Apache Commons sono più vecchie e soffrono un po 'del problema "troppi cuochi" ma hanno anche molte cose utili.

Trove ha raccolte molto specializzate per casi come chiavi / valori primitivi. In questi giorni troviamo che sui moderni JDK e con le raccolte Java 5+ e i casi d'uso simultaneo, le collezioni JDK superano anche le collezioni specializzate Trove.

Se hai casi d'uso con concorrenza davvero elevata, dovresti assolutamente provare cose come NonBlockingHashMap nella libreria su larga scala, che è un'implementazione senza blocco e che può calpestare ConcurrentHashMap se hai il caso d'uso giusto per questo.

java.util

Ci scusiamo per la risposta ovvia, ma per la maggior parte degli usi, le raccolte Java predefinite sono più che sufficienti.

Per memorizzare milioni di Stringin una mappa, dai un'occhiata a http://code.google.com/p/flatmap

Sono sviluppatore di happy-collection da happy-collection su source-forge

1. Collezioni basate su eventi
2. immodificabile
3. SortedList
4. nascondiglio

ConcurrentHashMap e il java.util.concurrentpacchetto devono essere menzionati se si prevede di utilizzare HashMap in più thread. viene considerato un ingombro di memoria ridotto, poiché fa parte del java standard.

Dipende da come definiamo "efficiente".

Ogni struttura di dati ha il proprio comportamento Big-Oh per la lettura, la scrittura, l'iterazione, l'impronta di memoria, ecc. È probabile che un elenco collegato in una libreria sia uguale a qualsiasi altro. E una mappa hash sarà più veloce per la lettura di O (1) rispetto a un elenco collegato O (n).

Ma quando leggo le risposte alla domanda "Le librerie Java gratuite più utili?" Ho notato che difficilmente viene menzionato.

Non sembra "il più efficiente". Sembra "il più popolare" per me.

Solo un feedback: non ne ho mai sentito parlare e non conosco nessuno che l'abbia usato. Le raccolte integrate in JDK, Google o Apache Commons sono famose per me.

Trove offre alcuni vantaggi.

• footprint di memoria ridotto, non utilizza oggetti Map.Entry
• puoi usare le strategie di hash invece delle chiavi per le mappe, questo fa risparmiare memoria e significa che non è necessario definire una nuova chiave ogni volta che vuoi memorizzare nella cache un oggetto su un nuovo set dei suoi attributi
• ha tipi di raccolta primitivi
• penso che abbia una qualche forma di iteratore interno

Detto questo, molto è stato fatto per migliorare le raccolte jdk da quando è stato scritto trove.

Sono le strategie di hashing che lo rendono attraente per me ... Google per trove e leggi la loro panoramica.

Se si desidera archiviare milioni di record in una tabella hash, è probabile che si verifichino problemi di memoria. Questo mi è successo quando ho provato a creare una mappa con 2,3 milioni di oggetti String, ad esempio. Sono andato con BerkeleyDB , che è molto maturo e si comporta bene. Hanno un'API Java che avvolge l'API Collections, quindi puoi facilmente creare mappe arbitrariamente grandi con un ingombro di memoria molto ridotto. L'accesso sarà più lento (poiché è memorizzato sul disco).

Domanda di follow-up : esiste una biblioteca decente (ed efficiente), ben mantenuta, per collezioni immutabili? Clojure ha un eccellente supporto per questo, e sarebbe bello avere qualcosa di simile per Java.