API to compress to multiple buffers about aircompressor HOT 7 CLOSED

I'm not sure that is possible without loosing a lot of performance. The core code makes assumptions about the memory being contiguous and adding the checks for the end of the buffer would likely slowdown the code significantly. Specifically, for compression the algorithms perform a single bounds check to verify that there is plenty of space in the output buffer, and do not perform an internal bounds checks, which makes them very fast.

Generally, I have found that for Hadoop formats this API is good enough since the compression is typically done is smaller chunks, and decompression typically has the output size.

Is there another shape that could work that doesn't need a multi-part output buffer?

from aircompressor.

I'm breaking the input stream into 256k buffers to compress, which for Snappy means that I need an output buffer of 306k. If we assume the compressed output is ~40%, that means that the output is 102k. To compress the next 256k block I either need to copy out the 102k or waste the empty 204k and make a new 306k buffer. I can't afford to use 3x the memory so I need to copy.

That said, I don't need to use every single byte in the output buffer as long as I know what is used. So if the compressor checked at reasonable points for the algorithm that would be fine.

Decompression is fine since I know exactly that the output will always be less than 256k. :)

from aircompressor.

In the case of snappy the algorithm will only compress 65536 bytes in one shot, and then uses an internal framing format, so a 256k buffer doesn't really help. For other algorithms, it can help.

I find that when I am compressing, I'm writing into a larger output buffer (1-8MBs) for a disk or network write, and I compress directly to that larger buffer until it is full. This shares the allocation across the entire stream lifetime. In your code, do you have access to a larger output buffer?

from aircompressor.

On a side note, I should finish a patch to add aircompressor support for ORC today. The code runs, I just need to add some new tests to check the new codecs and check compatibility with the old snappy code.

https://issues.apache.org/jira/browse/ORC-77

from aircompressor.

The problem is that I'm compressing all of the columns as they are written and I can't afford to have 1mb buffers per a column (users sometimes have thousands of columns).

Yeah, I knew that Snappy was putting in the 64k limit (unfortunately). I guess I should have Snappy restrict the buffer size, although as you point out it doesn't really change the underlying problem.

from aircompressor.

How does the current compression system work? I didn't think the snappy c code supported this kind of buffer management.

from aircompressor.

The old code had the copy, but I had a comment in to fix it at some point.

    // I should work on a patch for Snappy to support an overflow buffer
    // to prevent the extra buffer copy.

The current code for snappy in ORC is really sloppy and allocates a new output buffer for each block and then copies it into final buffer. I'll fix that as part of ORC-77 moving to aircompressor.

I guess ORC could allocate shared 8MB buffers and then capture the output of the compressor as slices of that buffer.

from aircompressor.