[Performance] will a decompressed bytebuffer cache help?

The flame-graph sampled from our production cluster shows that a large portion of CPU time has spent on LZ4Decompression (probably 60%+ of all querying related methods), as shown in the following picture.

I wonder would a (probably on disk) LRUCache on de-compressed data help?

It seems it would not be hard to implement. A, say, BufferedGenericIndexd can be created with a generated UUID, and then we can use <uuid>-bufferNumber as the cache key.

But I’m not sure about the effectiveness. It does introduce extra cost of cache miss penalty, random disk IO, etc.

That’s why I would like to raise a discussion here and find out is it a feasible solution.

Thanks

[drcrallen]

An alternative to this would be to just leave the data uncompressed (which is supported at indexing time currently), then let the kernel manage the page cache on its own. That way we wouldn’t need to do special buffer handling.

[litao91]

Thanks guys. It seems I need more investigation and evidence before dive into implementation.