Thanks for your feedback and comments, it's very valuable to me.
In my previous message, I mentioned that CPU is underutilized during installation. I haven't investigated further why, but I suspect it's due to the inefficiency caused by the usage of the loop device and/or inefficiency in the rsync itself.
In fact, I have an optimization to file next weekend on my to do list.
> All of the Live installations use rsync.
And that's what I propose to change: to use unsquashfs instead of rsync, preliminary benchmarks show 8x improvement in decompressing speed on local media for XZ on local storage.
On my PC configuration, that will require approx. 52.98 MiB/s sequential read performance from local media and approx. 181.19MiB writing speed to the destination media.
That level performance is not common among today's USB drives or optical media -- the installation speed will not be capped due to the CPU limits, but otherwise limited by the sequential read speed of the installation media. It means, selecting an algorithm with better compression ratio should reduce the installation time from commonly used USB storage.
Yes, Zstd consumes 12.24x less CPU user time while unsquashfs, but let's consider the practical application.
Will Zstd decrease the installation time, given the constraints and optimization above -- that's what I plan to investigate in upcoming weekends.
My proposal focuses on reducing the installation media size, and recommends to use certain compression options. But, I think, the final decision is to be made by FESCO.