The simulation runs slow

What the readout is telling you, and what makes a circuit expensive.

Read the second number

The header shows simulated seconds and a speed, for example 12.480 s 1.00x.

1.00x means the circuit is keeping pace with real time. 0.40x means a second of simulated time is taking two and a half seconds of yours. The first number is still correct: the simulation is not wrong, it is behind.

A sketch that never sleeps

This is the big one.

delay() parks the processor on a timer alarm rather than spinning. An idle sketch therefore costs the simulator a few hundred instructions per simulated second instead of the chip's full rate. A sketch that polls in a tight loop costs the whole rate: on the ESP32-C3 that is a hundred and sixty million instructions for every simulated second.

If your loop is while (digitalRead(2) == LOW) { }, that is where the time is going. Sleeping between reads, or using an interrupt, costs a fraction of it.

A circuit with a lot happening

The kernel is event driven: it wakes only the parts that saw a change. A few hundred parts at rest cost almost nothing. The same parts all switching at high frequency cost a great deal.

Things that generate a lot of events: a high clock frequency, a large WS2812 panel, and a capacitor in a fast RC network, since the capacitor is the one part that integrates over time.

A display being repainted

A full color TFT repaint is the most expensive single thing on the bench. Sketches that redraw a whole 240 by 320 screen every frame will show it in the readout; games here use a window instead, which is what the built-in Pong and Snake do.

The machine you are on

The CPU cores run at roughly the speed of the real chips on an ordinary laptop, which means a slower machine, or a busy one, moves the number down. Everything runs locally, so nothing about this is a queue you are waiting in.

The engine already runs in a Web Worker and gets the whole frame budget, so a heavy canvas is not what is costing you.

Things that do not help

Hiding a layer does not speed anything up: a hidden wire still simulates, because the netlist comes from the diagram and not from what is drawn.

Zooming out does not either.

What to try

• Replace a polling loop with delay() or an interrupt.
• Lower a clock part's frequency while you are working on something else.
• Take the large display or the long LED strip out until you need it.
• Run fewer boards at once.

The engine's own numbers, and what it costs per part and per net, are in what Mokxi simulates.