Tiny Core Extensions > TCE Talk
upx for large executables?
neonix:
upx -9 is gzip compression. All x86_64 cpus are so powerfull that you don't see a difference with gzip.
Try upx --ultra-brute and tell us what is the result when you use browser for many hours. How much RAM you have in your PC? How much RAM typical 64-bit TC user has?
On old wiki there was recomendation to use upx when you create new tczs. But it was in upx-9 era, now we have lzma era.
If you want for sure, how upx works, you need to read documentation or upx source code.
As far as I remember, compressed (upxed) program is decompressed in RAM on the fly (I don' sure about lzma) and it don't impact RAM in negative way. More pros than cons.
There's no way to change anything in tcz block compression, there's more cons than pros.
hiro:
can you back it up with real numbers?
i still didn't see any meaningful benchmarks.
i assume it's because you didn't try it out at all, you're just running your ideas by us. but next time, if you don't intend to run the experiment please at least put this into a disclaimer and don't pretend you know already the outcome of the experiment.
GNUser:
Hi CardealRusso. I can reproduce your experiment: If I squash brave-browser without specifying block size (i.e., using the 4K default), extension size is 180 MiB. If I squash using 64K block size, extension size is 155 MiB.
Hi curaga. I will follow your advice. For large extensions being submitted for x86_64 repo, I will check if there is significant benefit to using a block size larger than the 4K default. Is there a block size you would recommend as a sweet spot for x86_64 architecture? 64K? 128K?
curaga:
It depends on the data being compressed, can't really give a number.
GNUser:
Fair enough. Is there at least a range of sizes that you would consider to be reasonable?
EDIT: I just need a range to guide experimentation. I don't want to go above a block size that would be considered ridiculous ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version