The ~100K msg/sec on a Raspberry Pi and 1M+ on a modern server quoted on the home page come from this exact pipeline — 8 nodes, 900 temperature readings, end-to-end. The same flow now runs in your browser. The number below is yours, measured on your hardware.}
/>
---
## What's Being Measured
900 temperature readings flow through an 8-node pipeline:
noise filtering (sanitize, median3), dual exponential smoothing
(fast and slow), signal differencing, Page-Hinkley cumulative sum
test, persistence confirmation, and a controller that resets the
smoothers when a change is detected.
Each iteration creates fresh pipeline state, processes all 900
messages, and discards the output. The benchmark repeats until at
least one second of wall-clock time has elapsed, then reports
throughput.
This is end-to-end — partition creation, message cloning, state
updates, trigger dispatch, and result publishing. No shortcuts.
---
## Methodology
- **Timer**: `performance.now()` — sub-millisecond, monotonic
- **Warm-up**: one full pass before measurement (JIT priming)
- **Duration**: repeats until ≥1 second elapsed
- **Partitions**: single asset (one isolated state)
- **State**: fresh partition per iteration
- **Caveats**: browser results are typically 30–60% of native
Node.js throughput due to JIT differences and sandbox overhead
The reference hardware numbers use the same pipeline and dataset
in Node.js v22. To reproduce natively:
```bash
cd composer && node benchmark/compare.js 10 500
```
winkComposer is transitioning to open source. The benchmark script will be available in the public repository once the transition is complete.
---
## Next Steps
- [Hello Flow!](/docs/playground/hello-flow) — build this kind of
pipeline from scratch, one node at a time
- [Gradual Drift](/docs/playground/recipes/gradual-drift) —
the same fast/slow crossover pattern applied to industrial drift
- [Under the Hood](/docs/concepts/under-the-hood) — how messages
flow through the closure chain
---
# Engineering Notes
Source: https://composer.winkjs.org/docs/notes
---
# What 4KB of RAM Taught Me About Software Engineering
Source: https://composer.winkjs.org/docs/notes/what-4kb-of-ram-taught-me
Sanjaya Kumar Saxena
·
April 8, 2026
My first computer had 4KB of RAM.
Technically, 4K Words — the TDC-12 was a 12-bit machine, and the byte wasn't its unit. But the constraint was the same.
The TDC-12 — India's first indigenous digital computer. 12-bit architecture. I wrote self-modifying code on it. Not because it was clever. Because RAM was the constraint, and planning was the only way to survive.
You couldn't waste a byte. Every abstraction had to earn its place.
And floating-point arithmetic on a 12-bit machine? Wink at the wrong moment and your computation was silently corrupted. No exception. No warning. Just a wrong answer, quietly propagating forward. You learned a particular kind of paranoia — the kind that never quite leaves you.
Four things I took away that I have never unlearned:
1. **Constraints are not the enemy of good engineering. They are the teacher.** Infinite resources stop you from thinking. A 12-bit machine with 4KB forces you to think very carefully indeed.
2. **Planning is not overhead. It is the work.** The code was almost a formality. The real engineering happened on paper, before the machine was ever touched.
3. **Abstractions must be earned.** Every layer has to justify itself. An abstraction that does not reduce complexity is just confusion with better naming.
4. **Numbers lie if you let them.** Floating-point errors are silent. They do not throw exceptions. On a 12-bit machine, the margin for error was so narrow that you had no choice but to think through every computation before trusting it. That instinct has informed every numerically stable algorithm I have written since.
---
Forty-something years later — the tools have changed completely.
There is something worth noting for anyone reading it now.
Modern JavaScript runtimes like V8 do something conceptually similar — and far more sophisticated. On first execution, your code runs as interpreted bytecode. As functions get called repeatedly, V8 generates optimised machine code on the fly, based on observed runtime behaviour. If its assumptions are invalidated — a variable changes type mid-execution — it deoptimises, discards the compiled code, and revises its approach. The program's executable form changes during its own execution.
This is the V8 warmup you may have noticed in benchmarks. It is, at its core, a highly engineered descendant of the same idea.
The difference: in 1978, I did this by hand. In 4KB. With no safety net.
The tools have changed. The underlying idea hasn't moved an inch.
---
One acknowledgement I have carried for a long time: none of this would have happened without Prof. S. C. Gupta of IIT (BHU), Varanasi, India, who gave me unlimited access to the TDC-12. That kind of trust, given freely to a young engineer, shapes a career. It certainly shaped mine.
