I've been trying this patch (manually, not the complete script), but I have found this actually slows down the folio. There is a reason why flash-based devices don't have a swap. When writing large blocks to swap, the system will stutter heavily. The slow flash disk of the folio will not help in this. My test shows it is actually slowing down quite a bit.
Even with the low RAM of the folio, it is still faster to just start/restart an app than to swap it away in a swapfile (resulting in 1secs of stutter) and then getting it back anyway from disk.
ZRAM is something similar. Tough here I can understand some improved use cases, but:
- you take away precious RAM
- then you swap out programs and compress them (uses a lot of CPU)
- if you swap the program in again, you need to decompress. Granted, the decompress might be a little faster than restarting the app.
- because of the lower useable memory, programs do have an higher chance than before to be compressed (vs killed without ZRAM), so decompression (with ZRAM) statistically will happen more than restarting (without ZRAM), making the gains of ZRAM point 3 less.
- I don't think this works correctly with huge processes (e.g. browser), and will just see that less RAM is available, and will not swap out parts because the whole memory region is still in use (best case, it will continuously swap in & out parts, making it again slower)
I'm not completely trowing out ZRAM, as it is still beneficial with some workload combinations (I think a large collection of small apps is the most optimal case)