You are not logged in.
On this /r/archlinux thread, people were talking about the cool things they do with Arch, and I said I was a boot racer with <2s boot. People asked me to share my methods, and after procrastinating for 3 months I finally wrote it:
https://github.com/ranisalt/faster-computer-guide
It's currently not fully complete, as I did the tricks for the past 8 months and I don't remember them all, but some people already helped me with cool stuff I didn't even know ![]()
Please feel free to contribute and share your tips (and fix mine) for a faster using-a-computer experience, by posting here or creating an issue/pull request on Github.
Sorry if I posted on the wrong forum, I'm new here (hello all!).
Offline
Moving to Community Contributions (although it probably would be better off as a wiki page)...
Offline
A good deal of what you wrote seems to be already on the wiki
https://wiki.archlinux.org/index.php/Ma … erformance
https://wiki.archlinux.org/index.php/Im … erformance
I put at button on it. Yes. I wish to press it, but I'm not sure what will happen if I do. (Gune | Titan A.E.)
Offline
I'm reading through that atm and one thing you mention is setting the compression in mkinitcpio.conf to cat. According to this, lz4 might be a better choice. Decompresses almost instantly, but still compresses to about 36% of the original size.
[ Arch x86_64 | linux | Framework 13 | AMD Ryzen™ 5 7640U | 32GB RAM | KDE Plasma Wayland ]
Offline
A good deal of what you wrote seems to be already on the wiki
https://wiki.archlinux.org/index.php/Ma … erformance
https://wiki.archlinux.org/index.php/Im … erformance
Yes! Those are two great articles, and I also have some handpicked tricks I found on other sources, but I wanted to mainly have personal recommendations.
I'm reading through that atm and one thing you mention is setting the compression in mkinitcpio.conf to cat. According to this, lz4 might be a better choice. Decompresses almost instantly, but still compresses to about 36% of the original size.
I have found through personal experience that not compressing is faster since, although compressing renders a file 40% smaller, SSD is 4x faster than an average disk, so the bottleneck is not reading from the disk but decompressing. The time raw initrd takes to load is about 0.04s, while LZ4 takes on average 0.2s.
According to this the discard mount option can have a negative impact.
Just like the above, through personal experience I found it was good. It's cleaner than having a cronjob/systemctl timer to do the trim periodically too. Anyway, this post is old and his SSD probably had inferior technology, I tested uncompressing a big file then syncing and I had no performance penalty.
Both suggestions were added. Thank you all ![]()
Last edited by Ranieri (2015-08-25 01:10:24)
Offline