Speeding up Firefox on a USB Install With Persistence

[pbird]

During social distancing, I'm stuck at home with an IT-managed work laptop and I wanted to be able to make personal use of it. So I thought it'd be nice to try running MX Linux from a USB stick with persistence. I had a 128G USB 3.1 thumb drive laying around, which seemed promising, but it turned out that the I/O speeds were abysmal compared to slicker USB 3.1 devices like the SanDisk Extreme or Patriot Rage drives. Most of the system performed reasonably well (if a bit slugglishly at times), but every web browser I tried was not only slow to the point of being unusable, but would cause the CPU usage to spike to 100%, resulting in other applications and basic system functions locking up for seconds or minutes at a time.

The culprit was that Firefox was (as you might expect) writing its cache to the thumb drive and the slow I/O speeds were swamping the processor with wait operations. Forum user Head_on_a_Stick mentioned there was a way to have Firefox cache everything in system memory, rather than writing the cache to disk. So I decided to give it a shot and it turned out to work extremely well. The browser has gone from being unusable and locking up other applications to being highly responsive and playing well with the rest of the programs I have running.

To get Firefox to store the active profile, including the cache, in RAM I just followed the simple instructions on Verot.net, but with a few updates and MX-specific tweaks that I'll outline here.

First, where the Verot.net instructions tell you to change various values in Firefox's about:config settings, you also need to change one additional one. The setting `browser.cache.disk.smart_size.enabled' needs to be set to `false'. Otherwise, it will perpetually revert the changes you specified to the cache size.

Second, note that the profile for the `demo' user—the default user on the live USB install—is stored in the folder ~/.mozilla/firefox/xxxxxxx.default-release rather than ~/.mozilla/firefox/xxxxxxx.default (the x's here being placeholders for the auto-generated file name in each case). This means that the file path given in the Verot.net instructions (including the shell script it specifies) has to be tweaked accordingly wherever it appears.

Third, when you add the specified cron job (New to cron jobs? Start here.), you'll probably want to tack " >/dev/null 2>&1" onto the end to keep the system from spamming you with notification messages.

Finally, you'll need to edit the /etc/fstab file just as the Verot.net instructions specify to create a RAM partition for your Firefox profile. But be aware that the MX's live-USB setup makes it such that the /etc/fstab file is edited anew each time you boot. The first time I rebooted after following the Verot.net guidance, Firefox was broken again. It turned out that two lines had been run together in the automated edit of /etc/fstab, which made it so that the new RAM partition wasn't being recognized. I found that simply adding a few carriage returns on either side of the new line specifying the RAM partition in /etc/fstab solved the problem (the blank lines on either side keep the needed configuration code from being concatenated with another line of text).

That's it! I hope it works for others as well as it worked for me. Happy to clarify any confusion in the comments.

[carolus]

I think it suffices to choose the persist-root boot option to make Firefox write its cache to memory rather than to the thumb drive. For me, that sufficed to keep Firefox from freezing at 100% cpu on a USB2-only machine.