Tiny Core Extensions > TCE Talk

upx for large executables?

<< < (4/7) > >>

curaga:
The mksquashfs program supports up to 1mb, and if 1mb gives a good benefit over 512k, it's fine to use. The entire range is ok for 64-bit really.

GNUser:
Duly noted. Thanks!

hiro:
it depends on how the data is going to be accessed. as an example, if there's a huge video file embedded in the binary that plays an intro every time you open the application, in raw video format, it will be accessed sequentially in a big batch at startup and would benefit from an efficient high blocksize form of compression. even more, it would benefit from a lossy video codec.

these are 2 extremes.

a third extreme is if a binary is full of pre-computed lookuptables or something like that, and only a few entries are ever being looked at. then it would make sense to keep the blocksize small enough that most blocks with actual runnable instructions is mostly containing just those, and not whatever other never accessed data.

or, a program is extremely bloated and it contains everything and their grandmother: then you might be unlucky&lucky and most stuff is never accessed, or you might be just unlucky&unlucky and you'll page in everything bec. every second half-block has to be used!

CardealRusso:

--- Quote from: GNUser on May 17, 2024, 11:15:21 AM ---Fair enough. Is there at least a range of sizes that you would consider to be reasonable?

--- End quote ---
a hint


--- Quote from: CardealRusso on June 23, 2023, 05:38:04 PM ---CompSizeRamDecomp (Real)zstd(128k)119MB391MB0.37slz4(128k)181MB381MB0.35sgzip(128k)131MB379MB0.32szstd(4k)154MB385MB1.12sgzip(4k)160MB374MB1.15s
--- End quote ---

GNUser:
Interesting, but that's only two block sizes (so not enough to find a sweet spot). But this data suggests a larger block size results in smaller extension and faster decompression, with no significant difference in RAM usage.

Navigation

[0] Message Index

[#] Next page

[*] Previous page