←back to thread

SourceFS: A 2h+ Android build becomes a 15m task with a virtual filesystem

(www.source.dev)
137 points cdesai | 2 comments | 22 Oct 25 12:39 UTC | HN request time: 0s | source
Show context
DuckConference ◴[22 Oct 25 15:46 UTC] No.45670916[source]▶
Their performance claims are quite a bit ahead of the distributed android build systems that I've used, I'm curious what the secret sauce is.
replies(1): >>45671221 #
cogman10 ◴[22 Oct 25 16:04 UTC] No.45671221[source]▶
Is it going to be anything more than just a fancier ccache?
replies(1): >>45672002 #
vlovich123 ◴[22 Oct 25 16:59 UTC] No.45672002[source]▶
It’s definitely not ccache as they cover that under compiler wrapper. This works for Android because a good chunk of the tree is probably dead code for a single build (device drivers and whatnot). It’s unclear how they benchmark - they probably include checkout time of the codebase which artificially inflates the cost of the build (you only checkout once). It’s a virtual filesystem like what Facebook has open sourced although they claim to also do build caching without needing a dedicated build system that is aware of this and that part feels very novel
replies(2): >>45672269 #>>45677343 #
refulgentis ◴[22 Oct 25 17:21 UTC] No.45672269{3}[source]▶
Re: including checkout, it’s extremely unlikely. source: worked on Android for 7 years, 2 hr build time tracks to build time after checkout on 128 core AMD machine; checkout was O(hour), leaving only an hour for build if that was the case.
replies(1): >>45675024 #
1. serbancon ◴[22 Oct 25 20:54 UTC] No.45675024{4}[source]▶
Obviously this is the best-case, hyper-optimized scenario and we were careful not to inflate the numbers.

The machine running SourceFS was a c4d-standard-16, and if I remember correctly, the results were very similar on an equivalent 8-vCPU setup.

As mentioned in the blog post, the results were 51 seconds for a full Android 16 checkout (repo init + repo sync) and ~15 minutes for a clean build (make) of the same codebase. Note that this run was mostly replay - over 99 % of the build steps were served from cache.

replies(1): >>45677524 #
2. vlovich123 ◴[23 Oct 25 02:30 UTC] No.45677524[source]▶
Do you have any technical blog post how the filesystem is intercepting and caching build steps? This seems like a non-obvious development. The blog alludes to a sandbox step which I’m assuming is for establishing the graph somehow but it’s not obvious to understand where the pitfalls are (eg what if I install some system library - does this interception recognize when system libraries or tools have changed, what if the build description changes slightly, how does the invalidation work etc). Basically, it’s a bold claim to be able to deliver Blaze-like features without requiring any changes to the build system.