IppLZO1XST in LZO

[constantine-vassilev]

I am testing the LZO decompressing performance with different parameters using the code"
ippsEncodeLZOGetSize(IppLZO1XST, BUFSIZE, &lzoSize);
ippsEncodeLZOInit_8u(IppLZO1XST, BUFSIZE, pLZOState);

From documentation I am expecting BUFSIZE to not have an effect on IppLZO1XST:
"For the single-thread compression (method = IppLZO1XST) the size of the structure is
fixed, and the value of the maxInputLen parameter is ignored, for example, it can be set
to 0."

My tests show the followng:
IppLZO1XST
BUFSIZE 1024
Dcmp...
186488344 clocks, 116.000000 msec

BUFSIZE 1024*256
Dcmp...
186488344 clocks, 75.000000 msec

Performance gain is significant with bigger buffer, that is good, but
I would like to have explanation how this performance gain is achieved
if the BUFSIZE should not have an effect on the single-thread compression.

Thanks in advance,
Constantine

[Sergey_K_Intel]

Constantine,

Yes, you are right, that buffer size has no effect on IppLZO structure size in ST mode. Note, that only on structure size.
But, the buffer size itself definitely affects the performance.

It is not clear from your test output what it really does. What do clock and msec values mean? Especially, exactly the same clocks?

During decompression LZO behaves as a finite state machine.
I.e., it starts from the very first byte of compressed block and byte-by-byte does the decompression, doing this or that depending on byte value and its state.
Decompression doesnt require any buffers, dictionaries and other stuff. It starts from the very beginning and finishes, when it sees the end of compressed block.
So, if you have 2 times bigger compressed block, in general, you must spend about 2 times more time in decompression. This is why I was asking about numbers. May be msec number means msec/(1024 bytes) ?

Ha, I see Bigger buffer during compression, in general, leads to better compression ratio. So, it can take less time to decompress. But, again, in relative units only.
Decompression of 256*1024-size compressed block must not take less time than decompression of simple 1024-size compressed block.

If you want to provide us with more details about your test, youre welcome.

Regards,
Sergey