-
Notifications
You must be signed in to change notification settings - Fork 109
-
I know this sounds LOUD.
First of all, we need injection points, why not allow users to use the Brotli algorithm in their pipeline? A user could write a compressor and decompressor and use them in their closed environment, or even open-source these plugins as a separate library.
Second, if we have this extensibility, why not move all legacy and unpopular implementations into plugins as well? If you need ZipCrypto, inject it as a plugin. If you need legacy-zip, inject it as a plugin.
We would still have zero-cost+optimized main pipelines: aes -> (zstd, deflate, ...) -> crc. If a user wants to change it, they inject a plugin.
This would allow us to clean the library from many flags and options. Smaller error surface, easier reviews, and less load on maintainers.
Partly related to #204.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 2 comments
-
Just want to keep this table somewhere showing that the Tokio runtime has poor performance for active filesystem reads. Tokio uses readiness-based I/O and offloads file operations to a blocking thread pool, which can scale poorly for heavy disk workloads. Systems like Apache Iggy moved to a thread-per-core architecture with io_uring, allowing truly async disk I/O without a large blocking pool and improving scalability for storage workloads.
https://iggy.apache.org/blogs/2026/02/27/thread-per-core-io_uring/
It supports the idea that libraries shouldn’t rely on a single runtime but remain flexible.
Beta Was this translation helpful? Give feedback.
All reactions
-
Just a quote I want to save
Performance of dyn is not about the trait itself — it’s about where it sits in the call graph
Beta Was this translation helpful? Give feedback.