| 11 Apr 2026 |
 Atemu | And sandbox creation isn't something you can optimise that much further AFAIK | 10:12:17 |
| Atemu | (Ah, referring to per-file drvs here.) | 10:13:05 |
 magic_rb | If we could reuse the sandbox, as in cleaning out the build directory ought to be quick, we wouldnt have to set up a new sandbox from scratch | 10:16:34 |
| magic_rb | But idk | 10:16:38 |
 jaen | Yeah, what I was currently "doing" (or rather forcing Claude to do it for me - not going to say sorry for it, the only way I could reliably progress the PoCs between executive dysfunction and $DAY_JOB) and while it works well enough at the scale of Nix, at scale of Chromium and AOSP it buckles under itself in two different ways and the fixes seem to be in opposition to each other - having bigger chunks (so you rebuild more if something changes) vs. nesting more (so you pay more overhead, because you have more derivations). Now that I will hopefully be paid to do this full time, maybe I'll just find something the LLM was too dumb to chance upon. | 10:41:57 |
| jaen | Naively this goes with "bigger chunks" so you need to rebuild more on cache miss, I think. At least I couldn't side-step that so far. Alternatively, bazel seems to have a concept of persistent worker processes (https://bazel.build/remote/persistent), at worst maybe Nix could get something like that? | 10:43:57 |
| magic_rb | i mean not neccessarily | 10:44:15 |
| magic_rb | you can clean the sandbox, but not throw it away | 10:44:21 |
| magic_rb | if you kno youll be building 500 derivations you setup one sandbox and build everything in that sandbox with separate build directories. If i were to guess what takes the most time, its setting up the filesystem tree, but you can do that once with the union of all the closures. | 10:45:13 |
| magic_rb | Even if you end up having to setup separate pidnss or netnss it shouldnt be that slow | 10:50:26 |
| Atemu | You also have to mount store paths and I'm sure there are lots of relatively expensive steps necessary to ensure hermecity | 10:55:33 |
| jaen | I mean sure, but not with Nix as-is. I would assume those Bazel persistent workers are more less what you're talking about | 10:55:49 |
| Atemu | As I said, I tested this with a real nix-daemon a while ago and it did not scale | 10:56:12 |
| Atemu | I'm sure there are things you can do to make sandbox setups more efficient but not by that large of a perf gap | 10:57:02 |
| Atemu | But feel free to reproduce the experiment | 10:57:24 |
| jaen | I guess we'll see. Even if it's slower, then having to build less on cache just would be a win | 10:57:30 |
| jaen | * | 10:57:40 |
| Atemu | IIRC it was slow enough where even that was not a given | 10:58:19 |
| Atemu | I could see whether I still have the snippet to generate the stub drvs | 10:58:47 |
| magic_rb | Right exactly what i meant, as jaen said what im describing are probably bazel persistent workers. If we could skip the store path setup because we do it once for all of the robotnix derivations, that would make things faster | 10:58:49 |
| Atemu | I also think that module-level granularity is honestly good enough | 10:59:46 |
| jaen | Would appreciate, I do have something already, but comparing notes would be helpful, maybe I missed something obvious when I was paying it only part of my mind | 10:59:54 |
| Atemu | Most modules are stuff like basic OSS libs that do not change at all | 11:00:27 |
| jaen | For sure, granularity can just be one of the tuning knobs to use to find what is the most efficient | 11:01:45 |
| Atemu | I don't know how many inter-dependencies there are between android-specific components. Somethin, in me makes me think it might not even be that much. | 11:02:13 |
| magic_rb | I do want to point out, how robotnix is the most accessible way to build android tbh. Like, building it manually is something ive never managed, not that i tried that much | 11:04:39 |
| Atemu | {
total ? 200000,
random ? "foo",
sleep ? 0,
pkgs ? import <nixpkgs> { },
lib ? pkgs.lib,
}:
let
drvs = builtins.genList (
n: pkgs.runCommand "${random}-${toString n}" { } "sleep ${toString sleep} ; echo ${toString n} > $out"
) total;
list = lib.concatLines drvs;
in
pkgs.writeText "${toString total}" list
| 11:07:18 |
| Atemu | {
total ? 200000,
random ? "foo",
sleep ? 0,
pkgs ? import <nixpkgs> { },
lib ? pkgs.lib,
}:
let
drvs = builtins.genList (
n: pkgs.runCommand "${random}-${toString n}" { } "sleep ${toString sleep} ; echo ${toString n} > $out"
) total;
list = lib.concatLines drvs;
in
pkgs.writeText "${toString total}" list
| 11:07:25 |
| Atemu | Currently running with 10000 and it's still going.. | 11:07:50 |
| Atemu | Yeah, so running sleep 10000 times took 8min and I doubt that scales <linearly. At that point, it'd be faster to just build; especially given that real compiler invocations take quite a bit longer than sleep 0 | 11:58:30 |
