perf(gen_build): memoize classpath-files for is-aoted?

[english]

Depends on #90

Memoises classpath file listing in the is-aoted? path to avoid repeated scans of the same classpath
entries.

Change

• add memoised wrapper for classpath-files
• use memoised lookup in is-aoted?

Benchmark

examples/gen_srcs_bench (Hyperfine, 10 runs, prepare: delete src/**/BUILD.bazel)

• before median: 10.113s (mean 11.905s ± 6.529s)
• after median: 9.017s (mean 9.399s ± 1.827s)
• change (median): -10.84%

[arohner]

I'm surprised this works. AFAICT jar-classes is only called in one place, ->class->jar, and ->class->jar is only called in one place, srcs. Are there duplicate jars on the classpath?

[english]

not duplicate jars — it's the same jar/directory scanned once per namespace within it. ->dep-ns->label iterates each jar/directory on the classpath. for each one, it discovers all namespaces inside it, then calls should-compile-namespace? → is-aoted? → classpath-files(path) per namespace. so if a jar contains N namespaces, we were listing the same jar's contents N times.

I've pushed a commit that restructures instead of memoising: build the file listing as a set once per classpath entry, pass it through. also replaces the (some #(= ...) <list>) with (contains? set ...) which gets us O(1) lookups instead of O(n) linear scans.

benchmark (examples/gen_srcs_bench, hyperfine, 5 runs):

with --prepare 'find src -name BUILD.bazel -type f -delete' (full regeneration):

• baseline median: 13.155s
• memoise median: 10.899s (-17%)
• restructured median: 6.636s (-50%)

without prepare (no-op, BUILD files already exist):

• baseline median: 3.049s
• memoise median: 2.714s (-11%)
• restructured median: 2.560s (-16%)

(written by Claude)