34 votes

Compression rapide en Java?

Est-il très vite bibliothèque de compression pour Java? La norme gzip bibliothèque est plus lent que je le voudrais. Je suis à la recherche de quelque chose de similaire à http://www.oberhumer.com/opensource/lzo/ c'est du code Java natif qui fournit rapide de compression et de décompression. Merci!

Quelques autres de compression rapide bibliothèques de référence pour l'avenir:

QuickLZ - C/C#/Java - GPL ou commercial http://www.quicklz.com/

libLZF - C - licence de type BSD http://oldhome.schmorp.de/marc/liblzf.html

FastLZ - C - MIT licence de type http://fastlz.org/

LZO C - GPL ou commercial http://www.oberhumer.com/opensource/lzo/

zlib - C / Java (GZIP et deflate) Commercial convivial licence http://zlib.net/

Hadoop-LZO intégration (JNI): http://github.com/kevinweil/hadoop-lzo

Snappy-Java (JNI): https://github.com/xerial/snappy-java

Points de référence à partir de la QuickLZ gens: http://www.quicklz.com/bench.html

31voto

Peter Lawrey Points 229686

Vous pouvez utiliser le DeflatorOutputStream et InflatorInputStream. Ces deux utilisent la compression LZW. Vous pouvez simplement utiliser la bibliothèque qu'ils fournissent.

EDIT: la performance en temps Réel est généralement mesurée en termes de temps de latence, cependant, vous citez des chiffres en termes de throughtput. Pourriez-vous préciser ce que vous entendez par temps réel.

Pour la latence, à l'aide de la BEST_SPEED, chaque appel a eu 220 ns + 13 ns/octet en moyenne.

Remarque: dans une faible latence situations, vous obtenez souvent plusieurs fois le temps de latence que vous pourriez vous attendre lorsque le CPU est en cours d'exécution "à chaud". Vous devez effectuer la synchronisation dans une situation réaliste.

EDIT: C'est le taux de compression que j'ai obtenu avec Java 6 update 21;

Raw OutputStream.write() - 2485 MB/sec

Deflator.NO_COMPRESSION - 99 MB/s

Deflator.BEST_SPEED - 85 MB/s.

Deflator.FILTERED - 77 MB/s

Deflator.HUFFMAN_ONLY - 79 MB/s

Deflator.DEFAULT_COMPRESSION - 30 MB/s

Deflator.BEST_COMPRESSION - 14 MB/s

Note: je ne suis pas sûr de savoir pourquoi le paramètre par défaut est plus rapide que la "vitesse" de réglage. Je ne peux que supposer que l'ancien a été optimisé.

La taille de la mémoire tampon de sortie est de 4 ko, vous pouvez trouver une taille différente est la meilleure pour vous.

EDIT: Le code suivant imprime pour un grand fichier CSV. Le temps de latence est un bloc de 5 ko.

Average latency 48532 ns. Bandwidth 91.0 MB/s.
Average latency 52560 ns. Bandwidth 83.0 MB/s.
Average latency 47602 ns. Bandwidth 93.0 MB/s.
Average latency 51099 ns. Bandwidth 86.0 MB/s.
Average latency 47695 ns. Bandwidth 93.0 MB/s.

.

public class Main {
    public static void main(String... args) throws IOException {
        final String filename = args[0];
        final File file = new File(filename);
        DataInputStream dis = new DataInputStream(new FileInputStream(file));
        byte[] bytes = new byte[(int) file.length()];
        dis.readFully(bytes);
        test(bytes, false);
        for (int i = 0; i < 5; i++)
            test(bytes, true);
    }

    private static void test(byte[] bytes, boolean print) throws IOException {
        OutputStream out = new ByteOutputStream(bytes.length);
        Deflater def = new Deflater(Deflator.BEST_SPEED);
        DeflaterOutputStream dos = new DeflaterOutputStream(out, def, 4 * 1024);
        long start = System.nanoTime();
        int count = 0;
        int size = 5 * 1024;
        for (int i = 0; i < bytes.length - size; i += size, count++) {
            dos.write(bytes, i, size);
            dos.flush();
        }
        dos.close();
        long time = System.nanoTime() - start;
        long latency = time / count;
        // 1 byte per ns = 1000 MB/s.
        long bandwidth = (count * size * 1000L) / time;
        if (print)
            System.out.println("Average latency " + latency + " ns. Bandwidth " + bandwidth + " MB/s.");    
    }
}

20voto

StaxMan Points 34626

Plus on est de fous: il est rapide pur de la version Java de Snappy sur github. Il est actuellement le plus rapide pur java codec, et éventuellement, de la manière la plus rapide codec à partir de Java, même y compris C codecs (comme il est proche de la vitesse natif Snappy codec accessible via JNI).

Il y a donc 3 rapide Java des décompresseurs: Snappy, LZF et LZ4 (voir https://github.com/ning/jvm-compressor-benchmarkpour plus de détails

EDIT (août 2013): LZ4 est actuellement le plus rapide codec; Snappy et LZF partager la 2ème fente. Tous ont bien progressé au cours de la dernière année, et sont nettement plus rapides que GZIP.

7voto

StaxMan Points 34626

Un plus; une très efficace (Java optimisé, en référence) LZF la mise en œuvre au https://github.com/ning/compress. Plus rapide pour la décompression de dégonfler (gzip), 2x ou alors; et BEAUCOUP plus rapide pour la compression (3x - 5x). Taux de Compression plus faible, étant donné que c'est juste la première partie de dégonfler (Lempel-Ziv), sans la deuxième partie (le codage huffman); ce qui explique la plus grande partie de la différence de vitesse.

Nombres par la JVM compresseur de référence: https://github.com/ning/jvm-compressor-benchmark

2voto

flanglet Points 306

Les implémentations Java pur les plus rapides de LZ4 et Snappy sont les suivantes: https://code.google.com/p/kanzi/ Il existe une page comparant les performances de différentes implémentations java ici: https://code.google.com/p / kanzi / wiki / SnappyCodec . LZ4 est plus rapide et a un meilleur taux de compression (généralement) par une marge mince.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X