3 ms·

>Our internal testing shows that it performs very poorly for binary 3D vector data. Uh ? What format of data was this ? I did a pretty large test (2gb+) on OB

by gribbly 10y ago

>Our internal testing shows that it performs very poorly for binary 3D vector data. Uh ? What format of data was this ? I did a pretty large test (2gb+) on OBJ/STL 3d data and brotli compressed within ~5% margin of lzma, and this holds true on other binary data I've compared. It also compressed better than zstd (as in compression ratio) on the same data at their highest respective compression settings: bro -quality 11 -window 24 zstd --ultra -22 So I find it baffling that you find brotli to be poor for any binary data, could you share the data in question ?

haughter 10y ago
What is the compression time for brotli to achieve compression ratios comparable to LZMA on these types of data sets: https://github.com/google/brotli/issues/165 https://github.com/google/brotli/issues/165 I understand that brotli is incredibly slow as compared to LZMA when using these high ratio settings (q11, w24), so slow as to be impractical in production even in a write-once, read-many scenario if you have any non-trivial amount of data being regularly produced. I do not want to have a farm of machines just to handle the brotli compression load of our data sets just because it is 10x slower than LZMA.
- gribbly 10y ago
  >What is the compression time for brotli to achieve compression ratios comparable to LZMA... Compression time is indeed the achilles heel of Brotli, which is why it's something I would only use for compress once (and preferably decompress very often) scenarios. Compared to lzma at it's best compression setting for this particular data (-mx9 -m0=LZMA:d512m:fb273:lc8), brotli took 6 minutes and 4 seconds to compress, while the same data took 1 minute and 47 seconds for lzma. On the other hand, brotli decompressed the same data in 0.6 seconds, while it took lzma 2.2 seconds.
deleted 10y ago
[deleted]

by gribbly 10y ago

haughter 10y ago

What is the compression time for brotli to achieve compression ratios comparable to LZMA on these types of data sets: https://github.com/google/brotli/issues/165 https://github.com/google/brotli/issues/165 I understand that brotli is incredibly slow as compared to LZMA when using these high ratio settings (q11, w24), so slow as to be impractical in production even in a write-once, read-many scenario if you have any non-trivial amount of data being regularly produced. I do not want to have a farm of machines just to handle the brotli compression load of our data sets just because it is 10x slower than LZMA.

gribbly 10y ago
>What is the compression time for brotli to achieve compression ratios comparable to LZMA... Compression time is indeed the achilles heel of Brotli, which is why it's something I would only use for compress once (and preferably decompress very often) scenarios. Compared to lzma at it's best compression setting for this particular data (-mx9 -m0=LZMA:d512m:fb273:lc8), brotli took 6 minutes and 4 seconds to compress, while the same data took 1 minute and 47 seconds for lzma. On the other hand, brotli decompressed the same data in 0.6 seconds, while it took lzma 2.2 seconds.

deleted 10y ago

[deleted]