If reduce buffer size is not an option for you, you can always build own version of UZ, because source code included.
Go ahead, implement sais (or whatever you want) and show result to us.
I highly doubt about any big improvement with full buffer size. In any sorting algorithm.
Full buffer size is 0x40000 (and labeled as /* Hand tuning suggests this is an ideal size */
It is 262144.
log2(262144!) = 3 270 678.
It is lower bound of count comparator calls.
Currently qsort called comparator near 5 600 000 times.
So if you implement ideal sorting algorithm, it can call comparator 1.75 times less.
This is absolute maximum of speed improvement with same buffer size.
But you can go ahead and test all yourself.
For me (and I think for all others) buffer size does not matter, and little (1-2%) loss in compression not a problem at all.
For example if you have .unr file of 100 MB, this is mean it can be bigger to 2 MB. But 100 MB .unr file is totally insane.
Usually maps fits to 20 MB, so 2% it is 400 KB. 400 KB worth 100% CPU load for few hours in 2020 year? Or Internet speed allow us ignore this difference?
If you use dial-up modem 56kbps in 2020 year, I have bad news for you.
Currently UZ use buffer of size 0x2000. It can be 0x4000. It can give (or not) better compression. Maybe on 1%. But increase compression time twice.
I do not think 1% worst that. So I use 0x2000 not 0x4000.
CTF map from above built in 112 seconds, not in 63. I think this difference of size is less important rather then time for compress.
1 MB vs 60 seconds of compression - what is more important in 2020 year?