Wimlib is already the fastest and most storage efficient archiver we got in our real use case. And you manage to still improve performance
Yes, I keep the compressors and decompressors very well optimized. This is useful not just for wimlib specifically but also for learning about how to optimize LZ77-based algorithms in general and for reusing the code in other projects that need it, such as my NTFS-3G plugin for system compression (
https://github.com/ebiggers/ntfs-3g-system-compression).
wimlib-imagex uses LZX by default, and it is a compression format which has aged pretty well. Some newer formats are better, though not by as much as one may expect given that LZX is ~20 years old. The main problem with its use in WIM is actually just the fact that the default "chunk size" is limited to 32 KiB. In other words, every 32 KiB of data is compressed independently. This value is good for somewhat fine-grained random access, but I don't think that's an important use case given that even if you are doing "random" access, you likely should be doing more than 32 KiB of readahead per access anyway. A chunk size like 128 KiB would be more reasonable. For anyone who'd like to try it, wimlib-imagex lets you change the LZX chunk size to a larger value using the --chunk-size option, though the resulting archive will not be compatible with Microsoft's WIM software.
Oh and why not create a fork of ntfs-3G or submit patches? Wimlib is certainly the application which has the most intensive usage of ntfs-3G when applying huge partition images. What you would do with it could only benefit the other applications using it.
I actually have already been contributing bug reports, patches, and other improvements to NTFS-3G! As of the latest stable NTFS-3G release (2016.2.22), at least 11 unique bugs have been fixed as a direct result of testing via the wimlib project. I have also improved NTFS-3G's LZNT1 compressor, and the next NTFS-3G release is planned to support for transparently reading Windows 10 "system compressed" files via an external plugin (see:
https://github.com/ebiggers/ntfs-3g-system-compression). I am planning to keep contributing to NTFS-3G, as it very much needs more contributors (unfortunately, several individuals who would be very qualified to contribute to NTFS-3G have been lost to a commercial company which develops a proprietary fork of the software...).