Seeking seems slowish

[mxmlnkn]

Hello,

I now have more or less integrated your module into ratarmount to allow seeking in blocked xz files. I still need wheels to have it as a default dependency as I can't expect the user to build from source. However, there is another problem, in some use-cases which require 2000 seeks, I observed very slow speed (200x slower than the bz2 backend), which just doesn't make sense. Even emulated seeking should have been faster according to my calculations. It seems the seek function has some problematic time overhead.

Here are more details and tests:

Creating index with many recursive TARs inside an xz compressed TAR is 100x slower than bz2! #46

As the last real commit is 6 years ago, I have to ask: Is this project still maintained or are you willing to still maintain it? I'd be willing to do some pull requests.

[r3m0t]

Hi, I can merge pull requests if tests are added, this is also maintained separately in the pypy project.

Any seek other than to block_boundaries will be slow as the library doesn't cache any data to make backwards seeks faster. Forward seeks in the same block are done by decompressing any data from the current position to the desired position, and discarding it. Forward seeks into another block, or backward seeks into any block, are done by decompressing any data from the desired block's start to the desired position.