How to make Firefox builds 17% faster
141 points
8 hours ago
| 6 comments
| blog.farre.se
| HN
mmastrac
3 hours ago
[-]
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.

reply
estebank
3 hours ago
[-]
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.
reply
staticassertion
3 hours ago
[-]
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.
reply
estebank
49 minutes ago
[-]
Yes, I think here are workable designs.
reply
mmastrac
2 hours ago
[-]
Do you have a link for this one? Would love to see it.
reply
estebank
25 minutes ago
[-]
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

reply
NooneAtAll3
2 hours ago
[-]
what do you mean by idempotent and colpike?
reply
estebank
29 minutes ago
[-]
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.

reply
evmar
1 hour ago
[-]
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.
reply
jagged-chisel
55 minutes ago
[-]
Define “fixing.” If you’re building on ephemeral containers, an external cache is necessary for files that don’t change.
reply
allenrb
3 hours ago
[-]
I guess “purge 17% of the code” is not the correct answer?
reply
K0IN
5 hours ago
[-]
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.
reply
rtpg
57 minutes ago
[-]
managing deps as a separate project introduces a lot of day-to-day annoyances, especially if the files are actually changed decently often.
reply
Devorlon
6 hours ago
[-]
Why compile code when ccache faster
reply
amelius
5 hours ago
[-]
Does ccache fetch compiled code from a central server using checksums?
reply
fishgoesblub
3 hours ago
[-]
buildcache, the program the post is about can use a remote server for storing the cache.
reply
01HNNWZ0MV43FF
4 hours ago
[-]
sccache can, but most of us don't have access to an sccache instance: https://github.com/mozilla/sccache
reply
firesteelrain
15 minutes ago
[-]
We use sccache on prem with MinIO.
reply
mmastrac
2 hours ago
[-]
sccache is pretty easy to set up and you can back it with S3, memcache, redis, etc.
reply
shevy-java
4 hours ago
[-]
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.

reply
tadfisher
4 hours ago
[-]
I will just say this: it is unfortunate that you have chosen not to engage with the content of the article.
reply
jeffbee
4 hours ago
[-]
Considering that Firefox mainly appeals to its own contributors, making the developer experience better would be important.
reply
rebelwebmaster
2 hours ago
[-]
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.
reply