Can you (err... buildcache) cache Rust proc-macros? I've been battling this with sccache and I'm now maintaining a 10-patch deep stack for the next.js build CI.
Windows builds were ridiculously poor on cache hits rates too because of non-determinism that was not able to figure out.
There was an experimental PR that treats proc macros as idempotent with the corresponding colpike speed up. I don't know what happened with it, and stabilization required a lot of design work to not break backcompat. But this is something in the team's radar.
Would it be possible to do somethign like editions for proc macros, or have crates establish "this is a v2 proc macro" or something? There are a lot of things I'd love to see change in a v2 but it'd all be breaking.
Idempotent as in if the token stream in the input doesn't change, the cached result of the previous macro expansion is used during incremental, instead of being pessimistic and rerunning the macro.
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 full rebuilds (e.g. in C++ if some header file is touched that gets included by many files).
Another advantage as a local dev is that you can tap into the central CI cache and when you pull the latest trunk and build it, chances are that the CI system has already built that version (e.g. as part of a merge gate) so you will get cache hits.
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.
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.
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)
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, ...).
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 have been abandoned? "Firefox's frontend designers are doing frontend design work instead of implementing WebUSB which would immediately reverse their declining user share trend and make billions of dollars worth of donations! What are they thinking?!!"
(I'm gonna get a lot of hate for this post, aren't I?)
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 author here. I should've expected these comments, which makes me want to clarify a couple of things.
1. Just because I'm a dev at Mozilla and I got support for buildcache landed in the Firefox repo doesn't make this a Mozilla project. I do this on my own time to help me be more efficient when I actually work.
2. I mainly do this because it's fun. Including the blogging.
3. Sccache is still the compiler cache we're officially developing at Mozilla
For what it's worth, browser uptake is largely dictated by the browser being default shipped with some major OS. Very few users make an active choice (statistically speaking).
Safari is popular because it ships with iOS and macOS.
Edge (previously IE) is popular because it ships with Windows.
Chrome, however, is popular for several reasons. One reason is that it ships with Android and ChromeOS, but before that Google had a very aggressive multi-channel campaign where they pushed it with large banners on Google search (everyone used Google) and they made deals with Windows AV vendors so that when a user installed anti-virus on their computer Chrome was automatically installed and made the default browser. Another reason is that Google has consistently develeoped Chrome together with their web services, so things like search, maps, gmail, docs etc tend to work best in Chrome.
The only default channels that Firefox has, that I'm aware of, are verious Linux distros, and they have a pretty thin market slice.
Obviously it'll make the developer more efficient to spend more time twiddling his thumbs waiting for his code to compile rather than creating a simple build performance win that allows him to, you know, spend more time improving Firefox. Not to mention all the other developers who stand to benefit from faster builds.
Can you (err... buildcache) cache Rust proc-macros? I've been battling this with sccache and I'm now maintaining a 10-patch deep stack for the next.js build CI.
Windows builds were ridiculously poor on cache hits rates too because of non-determinism that was not able to figure out.
I'd be happy to test it out.
There was an experimental PR that treats proc macros as idempotent with the corresponding colpike speed up. I don't know what happened with it, and stabilization required a lot of design work to not break backcompat. But this is something in the team's radar.
Would it be possible to do somethign like editions for proc macros, or have crates establish "this is a v2 proc macro" or something? There are a lot of things I'd love to see change in a v2 but it'd all be breaking.
Yes, I think here are workable designs.
Do you have a link for this one? Would love to see it.
This is not the one I remember but another one that does part of what I'm describing.
https://github.com/rust-lang/rust/pull/145354
what do you mean by idempotent and colpike?
Idempotent as in if the token stream in the input doesn't change, the cached result of the previous macro expansion is used during incremental, instead of being pessimistic and rerunning the macro.
Colpike as in compile typo.
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.
Define “fixing.” If you’re building on ephemeral containers, an external cache is necessary for files that don’t change.
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 full rebuilds (e.g. in C++ if some header file is touched that gets included by many files).
Another advantage as a local dev is that you can tap into the central CI cache and when you pull the latest trunk and build it, chances are that the CI system has already built that version (e.g. as part of a merge gate) so you will get cache hits.
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.
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
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)
Only if your build scales linearly. Otherwise, it might be a different percentage.
wow, 17% is impressive with such an easy fix. i wonder if we could just build this as a separate project and pull the webidl files as a dependency.
managing deps as a separate project introduces a lot of day-to-day annoyances, especially if the files are actually changed decently often.
Disable all AI integrations? Sorry, I'll see myself out.
Why compile code when ccache faster
Does ccache fetch compiled code from a central server using checksums?
buildcache, the program the post is about can use a remote server for storing the cache.
And a local cache (kind of level 1 and level 2 caches)
sccache can, but most of us don't have access to an sccache instance: https://github.com/mozilla/sccache
We use sccache on prem with MinIO.
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, ...).
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 have been abandoned? "Firefox's frontend designers are doing frontend design work instead of implementing WebUSB which would immediately reverse their declining user share trend and make billions of dollars worth of donations! What are they thinking?!!"
(I'm gonna get a lot of hate for this post, aren't I?)
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 author here. I should've expected these comments, which makes me want to clarify a couple of things.
1. Just because I'm a dev at Mozilla and I got support for buildcache landed in the Firefox repo doesn't make this a Mozilla project. I do this on my own time to help me be more efficient when I actually work.
2. I mainly do this because it's fun. Including the blogging.
3. Sccache is still the compiler cache we're officially developing at Mozilla
I will just say this: it is unfortunate that you have chosen not to engage with the content of the article.
For what it's worth, browser uptake is largely dictated by the browser being default shipped with some major OS. Very few users make an active choice (statistically speaking).
Safari is popular because it ships with iOS and macOS.
Edge (previously IE) is popular because it ships with Windows.
Chrome, however, is popular for several reasons. One reason is that it ships with Android and ChromeOS, but before that Google had a very aggressive multi-channel campaign where they pushed it with large banners on Google search (everyone used Google) and they made deals with Windows AV vendors so that when a user installed anti-virus on their computer Chrome was automatically installed and made the default browser. Another reason is that Google has consistently develeoped Chrome together with their web services, so things like search, maps, gmail, docs etc tend to work best in Chrome.
The only default channels that Firefox has, that I'm aware of, are verious Linux distros, and they have a pretty thin market slice.
Obviously it'll make the developer more efficient to spend more time twiddling his thumbs waiting for his code to compile rather than creating a simple build performance win that allows him to, you know, spend more time improving Firefox. Not to mention all the other developers who stand to benefit from faster builds.
Considering that Firefox mainly appeals to its own contributors, making the developer experience better would be important.