perf: the next round of build speed (PERFORMANCE 9.6)

orion commented

2026-10-05 21:07:24 +00:00

Collaborator

Context

What is next for the front end and the compiler's own build, from PERFORMANCE.md 9.6. This is a tracking issue; the work is split into one PR-sized issue per step.

Steps

#204 List.equals as a loop (std; ready)
#205 Iterate.joined over the program lines as one sized copy (compiler; ready)
#206 parse the files of a program in parallel (compiler; ready)
#207 nested writes through a boxed container lowered as List.update (native + seed refresh; blocked on the owner decision below)
Before/after numbers in PERFORMANCE.md (new 9.7): each step PR adds its row.

Not in this round: keeping the parsed std between runs. It needs a cache location and invalidation rule (public behaviour); revisit after #206 is measured.

Acceptance criteria

#204, #205, #206, #207 closed (or recorded in PERFORMANCE.md 9.7 as measured and not taken) and PERFORMANCE.md 9.7 holds the before/after table.

Measurement

Forge CI only, no local bootstrap: the alternating-run processor times of main and PR binary are printed in the CI log (method of PERFORMANCE.md 9.5); the generated C stays byte-identical where a step promises it (tools/agree.sh emit).

Dependencies

None between #204-#206; #207 waits for the owner decision.

Notes

Seed impact: only #207 (new native, two-commit rule of CLAUDE.md "Seed and breaking changes"). The others add no native, syntax or looked-up name.

Moved from the planning lists of the docs; the design record stays the specification.

## Context What is next for the front end and the compiler's own build, from [PERFORMANCE.md 9.6](https://git.torb.dev/torbscript/language/src/branch/main/docs/PERFORMANCE.md). This is a tracking issue; the work is split into one PR-sized issue per step. ## Steps - [ ] #204 `List.equals` as a loop (std; ready) - [ ] #205 `Iterate.joined` over the program lines as one sized copy (compiler; ready) - [ ] #206 parse the files of a program in parallel (compiler; ready) - [ ] #207 nested writes through a boxed container lowered as `List.update` (native + seed refresh; blocked on the owner decision below) - [ ] Before/after numbers in PERFORMANCE.md (new 9.7): each step PR adds its row. Not in this round: keeping the parsed `std` between runs. It needs a cache location and invalidation rule (public behaviour); revisit after #206 is measured. ## Acceptance criteria - [ ] #204, #205, #206, #207 closed (or recorded in PERFORMANCE.md 9.7 as measured and not taken) and PERFORMANCE.md 9.7 holds the before/after table. ## Measurement Forge CI only, no local bootstrap: the alternating-run processor times of `main` and PR binary are printed in the CI log (method of PERFORMANCE.md 9.5); the generated C stays byte-identical where a step promises it (`tools/agree.sh emit`). ## Dependencies None between #204-#206; #207 waits for the owner decision. ## Notes Seed impact: only #207 (new native, two-commit rule of `CLAUDE.md` "Seed and breaking changes"). The others add no native, syntax or looked-up name. _Moved from the planning lists of the docs; the design record stays the specification._

orion added the

loop

label

2026-10-05 21:07:24 +00:00

orion commented

2026-10-08 14:24:30 +00:00

Author

Collaborator

[loop:torbscript] claim refine by session:loop-torbscript-20261008 until 2026-10-08T18:30:00Z

orion referenced this issue

2026-10-08 14:25:24 +00:00

perf: List.equals as a loop #204

orion referenced this issue

2026-10-08 14:25:24 +00:00

perf: join the program lines as one sized copy #205

orion referenced this issue

2026-10-08 14:25:24 +00:00

perf: parse the files of a program in parallel #206

orion referenced this issue

2026-10-08 14:25:25 +00:00

perf: nested writes through a boxed container lowered as List.update #207

orion commented

2026-10-08 14:25:37 +00:00

Author

Collaborator

[loop:torbscript] refine: split #144 into #204 (List.equals loop), #205 (sized join of program lines), #206 (parallel parse), all labelled ready, and #207 (nested write as List.update); #144 is now a tracking issue. Nothing in #204-#206 touches the seed.

[loop:torbscript] owner decision: #207 adds a native (ArrayList.update), a VM member and a lowering that looks up update, which is a seed refresh with the two-commit rule.

Options:

Go: do #207 in two steps (teach both forms, you refresh the seed, then migrate). Expected gain: removes the copy of the element on nested writes through boxed lists; not measured yet.
Not now: close #207 as not taken for this round and record it in PERFORMANCE.md 9.7.

Recommendation: option 2 until #204-#206 are measured, then decide with numbers; the nested-write cost was already fixed field by field in round one. Measurement in CI needs no local bootstrap for any step, but the seed refresh itself is yours.

v: 1
id: q1
asked_by: orion
to: torben
blocking: true
kind: decision
question: Do the seed-refreshing native List.update step (#207) in this round (option 1), or park it until #204-#206 are measured (option 2)?
options: 1 = go, two-commit seed change, 2 = park until the cheaper steps are measured
recommendation: 2

next: waiting (owner decision); #204-#206 are ready meanwhile (next: implement)

[loop:torbscript] refine: split #144 into #204 (List.equals loop), #205 (sized join of program lines), #206 (parallel parse), all labelled `ready`, and #207 (nested write as `List.update`); #144 is now a tracking issue. Nothing in #204-#206 touches the seed. [loop:torbscript] owner decision: #207 adds a native (`ArrayList.update`), a VM member and a lowering that looks up `update`, which is a seed refresh with the two-commit rule. Options: 1. Go: do #207 in two steps (teach both forms, you refresh the seed, then migrate). Expected gain: removes the copy of the element on nested writes through boxed lists; not measured yet. 2. Not now: close #207 as not taken for this round and record it in PERFORMANCE.md 9.7. Recommendation: option 2 until #204-#206 are measured, then decide with numbers; the nested-write cost was already fixed field by field in round one. Measurement in CI needs no local bootstrap for any step, but the seed refresh itself is yours. ```hos-question v: 1 id: q1 asked_by: orion to: torben blocking: true kind: decision question: Do the seed-refreshing native List.update step (#207) in this round (option 1), or park it until #204-#206 are measured (option 2)? options: 1 = go, two-commit seed change, 2 = park until the cheaper steps are measured recommendation: 2 ``` next: waiting (owner decision); #204-#206 are `ready` meanwhile (next: implement)

orion commented

2026-10-08 14:36:19 +00:00

Author

Collaborator

[loop:torbscript] owner decision recorded (torben via WhatsApp, 2026-10-08 16:35 Europe/Berlin): "Ja mach das, so was brauchst du mich nicht fragen" (yes, do it, no need to ask about such things).

Resolution: option 1, #207 is done in this round with the two-commit seed rule. #207 labelled ready.

Standing guidance from the same answer: "Das meiste davon konntest du selbst beantworten" (most of this you could have answered yourself). Decide performance steps, seed refreshes that follow an existing plan, naming that follows the conventions, and anything measurable on your own; measure before asking; large refactors are fine when they make sense, size is no argument against an option.

[loop:torbscript] owner decision recorded (torben via WhatsApp, 2026-10-08 16:35 Europe/Berlin): "Ja mach das, so was brauchst du mich nicht fragen" (yes, do it, no need to ask about such things). Resolution: option 1, #207 is done in this round with the two-commit seed rule. #207 labelled `ready`. Standing guidance from the same answer: "Das meiste davon konntest du selbst beantworten" (most of this you could have answered yourself). Decide performance steps, seed refreshes that follow an existing plan, naming that follows the conventions, and anything measurable on your own; measure before asking; large refactors are fine when they make sense, size is no argument against an option.

orion referenced this issue

2026-10-08 14:36:19 +00:00

perf: nested writes through a boxed container lowered as List.update #207

orion commented

2026-10-08 17:50:22 +00:00

Author

Collaborator

[question-closed] q=q1 reason=answered-elsewhere

orion commented

2026-10-09 06:50:47 +00:00

Author

Collaborator

[loop:torbscript] close: #204, #205, #206 and #207 are closed and merged (PRs #213, #238 and the earlier ones); their before/after rows are in PERFORMANCE.md 9.7 (List.equals), 9.8 (parallel parse), 9.9 (Iterate.joined), 9.10 and 9.11 (List.update). The numbering moved on since this issue named 9.7 as the single table, each step holds its own row. Closing.

[loop:torbscript] close: #204, #205, #206 and #207 are closed and merged (PRs #213, #238 and the earlier ones); their before/after rows are in PERFORMANCE.md 9.7 (`List.equals`), 9.8 (parallel parse), 9.9 (`Iterate.joined`), 9.10 and 9.11 (`List.update`). The numbering moved on since this issue named 9.7 as the single table, each step holds its own row. Closing.

orion closed this issue

2026-10-09 06:50:47 +00:00

Rows
Columns

perf: the next round of build speed (PERFORMANCE 9.6) #144

Context

Steps

Acceptance criteria

Measurement

Dependencies

Notes