build: cut the edit loop from 52s to 5s with more codegen units

zellij-server is one enormous crate and `fastdev` was building it in 16
codegen units, which is the granularity the incremental cache can skip work
at: a one-line change re-optimised a sixteenth of the crate. Splitting the
crates we actually edit into 256 units makes that a sliver instead.

Measured on the same one-line change to pane_boundaries_frame.rs, `git
checkout` of the file to a linked binary:

  codegen-units = 16    52s
  codegen-units = 256    6s, 4s on a second run
  + opt-level = 1        5s   (rejected: not worth a slower binary)

Ruled out on the way: linking the 69MB binary is ~2s, and rust-lld did not
beat the default linker on it, so the linker was never the problem. Root
crate codegen plus link is ~2s of the total.

Costs one 80s rebuild when switching profiles, and the fastdev binary keeps
opt-level 3. Verified with the full server/utils suites and make check-live.

3 files changed, 32 insertions, 2 deletions

diff --git a/Makefile b/Makefile
index 65b9909..015ea77 100644
--- a/Makefile
+++ b/Makefile
@@ -51,7 +51,7 @@ version: ## Print the sl0ppi version and what it is built from
 ##@ Build
 
 .PHONY: dev
-dev: ## Fast non-LTO build of sl0ppij (~3s incremental) for local testing
+dev: ## Fast non-LTO build of sl0ppij (~5s incremental) for local testing
 	cd $(FORK) && cargo build --profile fastdev -p $(CARGO_PKG)
 	@echo "-> $(FORK)/target/fastdev/$(BIN_NAME)"
 
diff --git a/docs/roadmap.md b/docs/roadmap.md
index 98c8949..cf7692c 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -264,9 +264,18 @@ rm sl0ppij/target && make build plugins
 `sl0pstatus/target` is already a real directory (572M).
 
 **Release builds are slow by design.** `make build` is 5m16s here (LTO,
-`codegen-units = 1`); `make dev` is the ~3s iteration loop. Do not put `make
+`codegen-units = 1`); `make dev` is the ~5s iteration loop. Do not put `make
 build` in an edit cycle.
 
+That loop was 52s until the `fastdev` profile started splitting the crates we
+edit into 256 codegen units. zellij-server is one enormous crate, so with 16
+units a one-line change re-optimised a sixteenth of it; the incremental cache
+can only skip work at codegen-unit granularity. Measured on the same one-line
+change, checkout to linked binary: 52s at `codegen-units = 16`, 6s at 256, 5s
+at 256 plus `opt-level = 1` (not worth a slower binary). Linking the 69MB
+binary is only ~2s, and lld did not improve on it -- the linker is not the
+problem here, and neither is opt-level.
+
 **pi version coupling.** `pi-ext/` targets pi's extension API, pinned at 0.84.1.
 Bumping the pin is an integration test, not a version bump.
 
diff --git a/sl0ppij/Cargo.toml b/sl0ppij/Cargo.toml
index 2e425f2..40c1347 100644
--- a/sl0ppij/Cargo.toml
+++ b/sl0ppij/Cargo.toml
@@ -182,6 +182,27 @@ strip = false
 incremental = true
 debug = false
 
+# sl0p: the crates we actually edit are split into many small codegen units, so
+# a one-line change recompiles a sliver of the crate instead of a sixteenth of
+# it. zellij-server is one enormous crate, and that is the whole edit loop:
+# measured on the same one-line change to pane_boundaries_frame.rs, from `git
+# checkout` of the file to a linked binary,
+#
+#   codegen-units = 16    52s      <- what the loop used to cost
+#   codegen-units = 256    6s
+#
+# opt-level is deliberately left at 3: dropping it to 1 saved another second
+# (5s), which is not worth a slower binary. Nothing else moved the needle --
+# linking the 69MB binary is ~2s, and lld did not improve on that.
+[profile.fastdev.package.zellij-server]
+codegen-units = 256
+[profile.fastdev.package.zellij-utils]
+codegen-units = 256
+[profile.fastdev.package.zellij-client]
+codegen-units = 256
+[profile.fastdev.package.zellij]
+codegen-units = 256
+
 [package.metadata.deb]
 depends = "$auto"
 license-file = ["LICENSE.md", "4"]