Keep compilation predictable

01 / LimitsReject oversized work early

Every schemd document is fenced in more than one sense of the word. There are hard ceilings, and the compiler enforces them before it does any real work:

The orthogonal router carries its own bounded search, too. A route it cannot complete comes back as an error — never a hang, and never a wire drawn straight through a component as though the obstacle were not there.

Compile on the server or during a build; cache the diagrams that do not change; and resist recompiling on every client keystroke unless the editor is debounced. Determinism is only a gift if you stop paying for it twice.

port:IN "Input" at (60, 160) #blue
resistor:R1 "1 k\Omega" at (240, 160) #amber
not:G1 "Condition" at (450, 160) #cyan [outputs=1]
port:OUT "Output" at (700, 160) #emerald

IN.out -> R1.in #blue [line]
R1.out -> G1.in #amber [ortho]
G1.out -> OUT.in #emerald [line marker-end=arrow]

02 / MeasureCheck a real output budget

Numbers beat intuition, so measure rather than guess. The reference beside this section is compiled on the server, and the figures worth watching are source bytes, SVG bytes, level-nine gzip size, and the true count of SVG elements the document emits.

Read them as measurements of this topology and mode — not as a universal benchmark. Labels, routes, markers, and interaction metadata each move the total, which is exactly why the honest answer to "how big is a schemd diagram?" is always "compile the one you mean and look."

port:IN "Input" at (60, 150) #blue
or:G1 "Aggregate" at (380, 150) #cyan [inputs=2 outputs=1]
port:OUT "Output" at (700, 150) #emerald

IN.out -> G1.in1 #blue [bezier]
IN.out -> G1.in2 #slate [bezier]
G1.out -> OUT.in #emerald [line marker-end=arrow]