Maximilian Knespel

Ah, I see. I think, this really is very related to #79 then but it goes one step further and would also combine data from "sibling" archives (those in the...

> > Could you paste one of those warnings? I'm beginning to doubt that it is normal. Also, what is the compression chain? It should only try to use an...

How many archives inside the outer archive are we talking about?

That is quite a lot and indeed might need more brainstorming and benchmarking :/. This might also trigger performance problems at other locations in the code, for example inside the...

Interesting, I haven't tried that yet. But reading concurrently is always a problematic case. When only a single process is accessing the mount point, it might result in sequential access...

I'm sorry for the late reply, I'm currently preoccupied with a [parallel gzip](https://github.com/mxmlnkn/indexed_bzip2) decoder, which coincidentally might also help alleviate your problem because you seem to test with a very...

I forgot one info: The gzip backend also has higher memory usage than e.g. bzip2 because the full 32 KiB gzip windows are held in memory for each seek point....

That sounds like a solid plan, yes. I think it shouldn't make much of a difference performance-wise whether the SQLite database is in-memory or not. I kinda trust SQLite in...

Please run the black code formatter. Personally, I'm running `tests/runtests.sh`, which also runs all code formatters and style checkers locally before running the actual tests.

I've tried merging it, see the `libarchive` branch. But, there are too many conceptual open issues, some of them inside python-libarchive, and missing or failing tests. That's why it has...