tansy
tansy
> With multi-threading the results may be I/O-bound I thought the whole corpus is read into memory. There is no 'I/O' in memory, is it? > Some MT implementation are...
> > Those 'internal' I know of libbsc(?), libsais, fast-lzma2, and now kanzi. > Also zstd but not so many of them. Zstd library uses threads internally? I thought it...
I have tried to separate these features so compression, decompression and codec threading are separete. [First attempt](https://onlinepaste.com/raw/576/70bdcd) tried to parse input and get them separately. By the way I thought...
I do not insist on separate compression and decompression thread pools. I only observed this original behaviour where it uses different compression and decompression threads on its own, automatically. ```...
There were more of them than I thought.
> Results with 1 thread: Fastlzma2, lzham decompression results are suspiciously high, and higher with lower compression levels, which is illogical. Compare it to xz, or lzlib and you will...
Well, it looks like fastlzma2 in your last test is ok - around 100 MB/s decompression, on par with lzma, and increases with compression, which is normal too.
Looks fine.
How about adding threading support to codec list? I tried this [thing](https://dpaste.com/3HJNB3PQ4) and it's somewhat useful if you want to find out which codec supports threads. Not sure if it...
\`threading=-T' is redundant. They all support it and none of them does, in the same time. It's like multithreading in lbzip2/plzip - it's done by client not by compressor library...