Live data from Hacker News

How to make Firefox builds 17% faster

blog.farre.se

31–38 of 38 posts

Re: How to make Firefox builds 17% faster

#31

Earlier quoted context omitted.

sccache can, but most of us don't have access to an sccache instance: https://github.com/mozilla/sccache

sccache is pretty easy to set up and you can back it with S3, memcache, redis, etc.

Same with BuildCache, except you also get a fast local cache so you effectively have an L1 and an L2 cache.

In fact, since you also have super fast "direct mode" caching that bypasses the preprocessor (like ccache but unlike sccache), BuildCache really has three logical levels of cache: direct, preprocessor and remote (S3, redis, ...).

Re: How to make Firefox builds 17% faster

#33
post #18

I’m not too familiar with Firefox builds. Why are clobber builds common? At first glance it seems weird to add a cache around your build system vs fixing your build system.

Though I'm not actively working with Firefox so can't speak for their use cases, one important use case for clobber builds is CI. I'm the author of BuildCache, and where I work we make thousands of clobber builds every day in our CI. Caching helps tremendously for keeping build times short. There are a few use cases for local development too. For instance if you switch between git branches you may have to make near f…

I see, I might be confused by the terminology. "clobber" to me suggests intentionally trying to throw away cached results (clobbering what you have), but it sounds like you might just use it to mean builds where you don't have any existing build state already present.

Re: How to make Firefox builds 17% faster

#34
post #11

I guess “purge 17% of the code” is not the correct answer?

If you can remove 17% of your code, or even just avoid building it, yeah you probably should. That can be a really rough tradeoff though. (And the sibling comment is also right that deleting 17% of code != 17% faster builds, though I could see it being higher or lower)

Re: How to make Firefox builds 17% faster

#35
post #18

I’m not too familiar with Firefox builds. Why are clobber builds common? At first glance it seems weird to add a cache around your build system vs fixing your build system.

What even is a 'clobber build'?

Sorry for being unclear. I'm using Firefox build system lingo without explanations. It's from the command `./mach clobber`, which is similar but not the same as `make clean`. I use 'clobber build' as "a build with no existing build state" and the qualifiers "cold" and "warm" to indicate if cache is empty or filled.

Re: How to make Firefox builds 17% faster

#36

Earlier quoted context omitted.

What even is a 'clobber build'?

Sorry for being unclear. I'm using Firefox build system lingo without explanations. It's from the command `./mach clobber`, which is similar but not the same as `make clean`. I use 'clobber build' as "a build with no existing build state" and the qualifiers "cold" and "warm" to indicate if cache is empty or filled.

Ah ok, thanks

Re: How to make Firefox builds 17% faster

#38
post #25

So ... perhaps Mozilla should focus on user share dropping. I understand that speed is relevant, but focusing on that strategy does not really work when dinosaur-like extinction is around the corner.

Aw shucks, we never thought of that. Here we were, dedicating every one of our developers to speeding up the build, and we never thought to increase our user share instead. In retrospect, that was pretty dumb! Ok, sorry, we'll get right on that. Seriously, what is with the trend of assuming that anything anyone in a project does, it is assumed that it has been the main goal of the project and all other objectives hav…

I mean, if you could donate directly to Firefox development and not for "anything Mozilla wants to waste it on that day", maybe the donations would go up.
Post reply on HN