One archive per machine, not one per image #26

2026-09-14T17:58:14Z

jschoubben commented

2026-09-14 17:58:14 +00:00

The images a bed stocks are almost entirely the same bytes. The base they share is 227 MB; a module's own compiled code is a few. Exported one at a time, that base is written, pushed and loaded once per image — for the four-machine bed the same 227 MB crossed thirty-odd times, and the whole set measured 9.7 GB.

Measured on eight of them: 2.24 GB as separate archives, 0.29 GB as one. 87% less, and the saving grows with the count.

This matters beyond tidiness. Stocking is the slowest thing a raise does, and the four-machine bed has been exceeding its own ninety-minute limit while still copying — so its last run failed on the clock rather than on anything it was testing.

The loop is inverted: images are grouped by destination machine and exported together. Validation moves ahead of any transfer, so a scenario naming something it should not is refused before a machine is touched. The read-back of what each machine calls each image is unchanged, and the check that every machine agrees on one reference now compares across machines explicitly rather than relying on loop order.

Also in here: the build scripts stop shipping a compiler in every module image. The image runs compiled code and never compiles any — tsc runs on the workstation. That is 26 MB an image, small beside the above, but it was pure waste.

The images a bed stocks are almost entirely the same bytes. The base they share is 227 MB; a module's own compiled code is a few. Exported one at a time, that base is written, pushed and loaded once *per image* — for the four-machine bed the same 227 MB crossed thirty-odd times, and the whole set measured 9.7 GB. Measured on eight of them: **2.24 GB as separate archives, 0.29 GB as one. 87% less**, and the saving grows with the count. This matters beyond tidiness. Stocking is the slowest thing a raise does, and the four-machine bed has been exceeding its own ninety-minute limit *while still copying* — so its last run failed on the clock rather than on anything it was testing. The loop is inverted: images are grouped by destination machine and exported together. Validation moves ahead of any transfer, so a scenario naming something it should not is refused before a machine is touched. The read-back of what each machine calls each image is unchanged, and the check that every machine agrees on one reference now compares across machines explicitly rather than relying on loop order. Also in here: the build scripts stop shipping a compiler in every module image. The image runs compiled code and never compiles any — tsc runs on the workstation. That is 26 MB an image, small beside the above, but it was pure waste.

jschoubben added 1 commit 2026-09-14 17:58:14 +00:00

One archive per machine, not one per image 5d1f7762c2

The images a bed stocks are almost entirely the same bytes: the base they share
is 227 MB and a module's own code is a few. Exported one at a time that base is
written, pushed and loaded once per image — for this bed, the same 227 MB crossed
thirty-odd times, and the whole set measured 9.7 GB.

Measured on eight of them: 2.24 GB as separate archives, 0.29 GB as one. 87 per
cent less, and it improves with the count.

This is the slowest thing a raise does, and the four-machine bed has been
exceeding its own ninety-minute limit while still copying — so it was failing on
the clock rather than on anything it was testing.

Also stops shipping a compiler in every module image. The image runs compiled
code and never compiles any; tsc runs on the workstation. Worth 26 MB an image,
which is small beside the above but was pure waste.

jschoubben merged commit 7fa1f1f0bb into main

2026-09-14 17:58:20 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-lab#26