Mercury – Compiler optimized, private Firefox fork
thorium.rocks
thorium.rocks
The results were underwhelming.
Secondary is that compiler optimisations are prone to creating binaries that don't work like the less optimised version. Not everyone has the hardline "if it changes behaviour it's a bug, not an optimisation" perspective. Those that do still make mistakes.
LTO is really good at detecting aliasing violations between translation units which were previously benign but can now be "optimised" into ruin.
PGO was originally changing branch probabilities which should be harmless but I haven't looked recently, it might be more aggressive now.
LibreWolf, AFAIK, has been hyper aggressive on privacy preferences (to the detriment of a useable web sometimes) and is its USP.
I used to be quite aggressive with compiler optimisations - but all you are really doing is introducing instability and more often than not, performance regressions.
For the latest release, I actually started including polyhedral optimisation provided by the LLVM Polly project, but the effort resulted in essentially 0 performance gain. It was to be expected, as polly isn't really going to net general performance improvements, especially with the type of work a browser is doing.
It's also VERY easy to mislead yourself when adding these optimisations by getting a good run on a benchmark once or twice, yet you could try another run and get a different result. I am guilty of this myself, it took a long time to realise the mistakes I was making.
The reality was, I found, running on fresh device in comparison with Firefox, was almost no difference. The majority of performance improvements came from the engineering effort put in by Mozilla themselves and they are VERY good at that. The devs are also conscious of the available compiler optimisations and make a very good effort to include any that make a difference.
> Compiler optimizations include AVX, AES, LTO and PGO.
Firefox already does LTO and PGO, and for majority of the code, where AVX is beneficial, it is already included with code dispatch if the CPU supports it (for example with media codecs). The same goes for AES in the NSS library.
Does that mean you can't get Clang/LLVM to generate AVX instructions? Yes, I'm sure it does. Does it actually make a meaningful difference? No. Not that I've found from years of doing this and eventually just abandoning it.
The only time I ever saw big, proper gains from compiler optimisation alone was when I was compiling Waterfox with Intel's C++ compiler and using auto dispatching with the Qax [1] flag. Intel were doing some magic there. But the effort to get the Firefox codebase compiled with it was nothing short of sisyphean and essentially an exercise in masochism.
[1] https://www.intel.com/content/www/us/en/docs/cpp-compiler/de...
The latter is more secure in almost every case, in almost every way you can analyse the problem, but at a human level it's easier to trust one person whose name you know over a company where you can't point to any specific individual.
When you know someone personally then perhaps this is a reasonable trade-off to make, but "on the internet nobody knows you're a dog"[1]. People form parasocial relationships with individuals, movements, influencers, etc, and really there's not much to trust about them.
[1]: https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_...
An individual may be more likely to agree with your own definition of "malicious".