Execution Time

You've got a workflow that's slow and you don't know why. Every node runs, the thing finishes, but some step is clearly eating the whole budget - the first KSampler? the upscale? a video node? ComfyUI ships almost no introspection for that, which is a real hole for a tool where workflows are graphs of a dozen or more stages. Execution Time (TY_ExecutionTime) from ComfyUI-Dev-Utils is the fix: drop it into any graph, run once, and every node in the workflow gets a badge in its top-left corner showing how long it took and how much VRAM it used. That's the whole pitch, and for debugging it's a genuinely good one.

It's the profiling half of ComfyUI-Dev-Utils, a small MIT-licensed dev-utility pack by ty0x2333 that also ships a log console, a URL downloader, an upload-anything node, and reroute enhancements. This is the part people actually talk about.

How it works

The node itself has no inputs and no outputs, and its process function does nothing. It's a hook, not a worker. On import, the pack monkey-patches ComfyUI's execution engine (execution.execute) and the server's event broadcaster (PromptServer.send_sync). When a run starts it records time.perf_counter() and a peak-VRAM baseline for each node as that node begins, then measures the delta when each node finishes and pushes the numbers to the frontend over ComfyUI's SSE socket. The frontend draws the badges and a live timer that ticks up on whatever node is currently running.

It's not a profiler in the cProfile sense - no per-operator timing, no sampling. It's wall-clock time per node plus VRAM deltas. For "which node is my bottleneck," that's exactly the right tool.

The node's table shows each node's current run time, its last run time, and the difference between them, plus a Max row for the longest node and the workflow's peak VRAM. There's a CSV export button, which is genuinely useful when you're tuning a workflow over many runs and want the numbers somewhere you can diff them.

How to use it

Add the node, hit run, done. Badges only appear after the first execution completes, and the whole graph gets measured - you just need this node present as an observer. Don't try to wire anything into it; there's nothing to connect.

Install

Via ComfyUI Manager: search "ComfyUI-Dev-Utils" and install. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ty0x2333/ComfyUI-Dev-Utils.git
cd ComfyUI-Dev-Utils
pip install -r requirements.txt

Then restart ComfyUI. No models to download. The only pinned dependency is aiohttp-sse, and that's for the pack's log console, not this node.

Where people get burned

This is a monkey-patch against ComfyUI internals, and ComfyUI changes internals constantly. The pack's changelog is basically that story: a fix for the async execution rewrite, a fix for the pending_async_nodes signature change, a fix for the latest ComfyUI update. The drill is to keep both ComfyUI and the pack updated, and if badges stop appearing after a ComfyUI update, that's the first thing to suspect. The author keeps up, but there's a lag between each ComfyUI change and the patch.

Two real limits come from how the frontend stores the data: timing lives on node objects, so it evaporates when you switch graphs, and anything inside a subgraph is invisible to the profiler - it only walks the root graph. Fine for most workflows, a known gap if you live in subgraphs. It also coexists with other profiler packs like comfyui-profiler or Easy-Use; they just fight over badge space visually rather than breaking each other.

Verdict

Not a daily-driver node - it's a debugging tool you add, measure, and remove. But the moment you're asking "why is my workflow slow," this answers in one run.