Mod 26: faster execution, a smaller footprint

Mod 26 is a performance release. No new nodes, no new surfaces — the same product doing the same work considerably faster, in noticeably less memory, and staying that way.

Bursts finish in a fraction of the time

The case that got the most attention is the one that matters to anyone running on a schedule: a lot of workflows starting at the same moment. The top of an hour, the start of a shift, a nightly batch.

That case is dramatically faster. Where a large burst used to take minutes, it now takes seconds — and the machine spreads the work across its cores rather than working through it a few at a time. If you schedule work for a specific time because that time matters, it now starts when you asked.

Runs cost less memory

The data moving between the steps of a workflow is held far more compactly. The same workflows run in noticeably less room, which shows up most when many run at once, or when one workflow carries a lot of records.

Finishing a large run used to cause a memory spike as the run was written to history. It doesn't any more, which took real pressure off smaller machines — the kind of pressure that ends in a restart.

Installs stay fast

This is the one we're most pleased to have found. Stored run history had been accumulating in a way that made every finishing run slightly slower, without limit. Nothing looked wrong: the number of runs kept was always correct. But an install that had been up for months was doing measurably more work per run than one installed yesterday, and the gap kept widening.

That no longer accumulates. And an install that had already slowed down repairs itself on first start, reclaiming the storage it was holding — with its run history intact. A long-lived install comes back to the speed it had on day one.

Faster startup

Less time between a trigger firing and the first step running.

---

Everything upgrades in place and keeps its data. No workflow changes are needed; existing workflows simply run better.