When I boot to ram I like to have a puppy sfs that is the most tightly compressed, xz high compression type choice. When instead I boot with the nocopy to ram type alternative the sfs filesize is much less relevant and I go with the lz4 compression choice for its speed of decompression.
With the former you might end up with a 333MB sfs file copied into ram, and if all of that is accessed during a session that might eat another 1GB of ram (cache/swap) being used i.e. assuming a 3:1 type compression. Maybe 1.3GB of ram being used, just for files.
For the latter the compression might be more like 2:1, but where reading 100MB from disk where decompressed = 200MB of data/program can be faster than having read 200MB of non compressed data/program from disk i.e. lz4 decompression speeds can be faster than disk read speeds (especially when multiple cores are being used). An where once booted perhaps only 250MB of ram is being used.
Much is subject to whether your kernel has been compiled to support xz, lz4 (whatever) compression methods, some distro/kernel providers opt to just support gzip, all depends upon how the kernel was compiled. More often you can run zcat /proc/config.gz in a terminal window to see what settings were used to compile a kernel. If that contains something like SQUASHFS_LZ4=y and HAVE_KERNEL_LZ4=y entries, then lz4 compressed sfs's may very well be supported.
To convert a sfs I tend to uncompress it, i.e. on a ext type partition/folder that has plenty of free space ...
unsquashfs puppyxxx.sfs
that creates a squashfs-root folder of the content, and then create another sfs using the desired compression choice
mksquashfs squashfs-root puppyxxx.NEW.sfs -comp lz4
and then remove the squashfs-root folder when done
rm -rf squashfs-root
and then that original puppyxxx.sfs can be swapped out (renamed) for the new version, before rebooting into the new version. Best done on a system with multiple boot choices so if it doesn't work you can boot into a working system and rename things back to as they were before. And of course after having made backups of your savefile/folders/data.
I used to boot looking to load everything into ram such that the HDD could be isolated after bootup for security reasons. Subsequently I moved over to booting with the nocopy type style in order to minimise the amount of ram used, in order to leave more ram available for concurrent dual booting i.e. where I use kvm/qemu to boot another system, so that both systems are available at the same time. I primary boot Fatdog, and then kvm/qemu boot OpenBSD (I prefer to use OpenBSD for browsing for its better security). Note that in Fatdog the boot command differs to that of Puppy systems i.e. it uses a 'basesfs=direct:...' parameter instead of 'basesfs=ram:...' parameter and where the humongous sfs has been separated out (its all documented in the Fatdog help, search for 'humongous').
Using a larger but faster lz4 compressed puppy sfs will tend to see programs start up quicker the first time than if gz or xz compressed puppy sfs was used. But once loaded once, more often the system will keep things cached such that subsequent starting of a program will be little/no different - as whichever way the program will already be in cache (ram), so no difference is speed whether booted using copy to ram, nocopy or whether the sfs was compressed using xz, gz or lz4.
