Run Timer

You change a sampler, a step count, an attention patch - and the run "feels" slower. Feels is doing a lot of work there. ComfyUI's console prints per-node timings if you scroll back far enough, and the progress bar disappears the moment you notice it, so the practical answer most people settle on is: guess.

Run Timer (QG_RunTimer) puts a stopwatch on the canvas. It starts when a queued prompt begins executing, ticks while it runs, and holds the total when it finishes. No inputs, no outputs, no wires - the node is the readout, painted by the frontend, driven by listening to the queue state rather than sitting in the execution graph.

How it works

There's no data flowing through it, so there's nothing for the backend to compute. The decision logic lives in the pack's frontend module: it watches for queue execution starting, counts while it runs, stops when the queue empties, and repaints the node. Because the elapsed time is stored as a node property, it's saved inside the workflow file - open someone else's shared workflow and their run time is right there on the canvas as a reference point.

That's a small thing that turns out to be genuinely useful when you're downloading workflows. "This took 4m12s on the author's machine" is a much better signal than discovering it takes 27 minutes on yours after the fact.

Right-click gives you the last few runs rather than just the current one. That's the feature that makes it a tool instead of decoration: change one setting, run, compare 3m41s to 4m02s, decide in five seconds. The KB's troubleshooting material is full of "is this supposed to be this slow" threads, and the honest answer is that nobody can tell you without a baseline. This gives you one.

Inputs and outputs

None. INPUT_TYPES is empty, there are no sockets on either side, and the node never enters a prompt - the backend method is a no-op that's never reached because a node with no outputs isn't part of any execution. Everything you see is frontend.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/live1617/ComfyUI-QG-tools

Then a full restart - the console should print [QG-tools] v0.9.2 加载完成 | 节点数 24. Manager search ComfyUI-QG-Tools works where the registry listing exists. Zero dependencies: the requirements file is comments-only by design so Manager runs no pip step, and this node has no Python work to do anyway.

Ported from AusBoss (MIT). Search timer, run time, stopwatch or 耗时.

Where people get burned

It times the queue, not your node. The number is the whole graph's wall-clock, including model loading and the VAE decode and the save. It will not tell you that your new ControlNet pile added eleven seconds - for that you want per-node timing from the console, or a benchmark node either side of the suspect. Use this one for "did the workflow get slower", not "what got slower".

First run is always slower. Weights get loaded, kernels get compiled, the page cache fills. If you compare a cold first run against a warm second one you'll conclude nonsense. Run twice, judge the second.

A stale number persists in the file. Since the time is saved with the workflow, a shared graph shows the author's number even if you never queue it. It's a reference, not a claim about your machine - and if you're publishing workflows, it's worth a note card telling people roughly what hardware produced it.

It doesn't survive a page reload mid-run. The count is frontend state. Reload the browser while a queue runs and you'll be looking at whatever the node last recorded. Not a bug, just what "frontend only" means.