👑 FRED Execution Time

Benchmarking a workflow in ComfyUI is usually done by squinting at the console timestamps and doing mental math. FRED_ExecutionTime gives you an actual number: the total duration of your prompt run, in seconds with two decimals, as a node output you can wire anywhere.

How to use it

The setup is dumb simple: connect this node's tail input to the last node in your workflow - the final save, preview, or whatever terminates the chain. It needs to come after everything you care about timing. Then read the outputs:

• execution_time_sec (FLOAT) - the run duration in seconds.
• execution_time_str (STRING) - the same value formatted like 12.34s, ready to drop into a text display or a filename token.
• help - the pack's usual usage card.

How it actually works

This is the part worth a little respect. A naive timer that just logs at node execution would time only that single node, not the whole graph. This one uses a process-wide singleton timer: a shared timer object is started/reset for the prompt run, and because the node executes last in the graph, it stops the timer after everything else has finished. The implementation keys the timer to the prompt run so consecutive runs reset cleanly instead of accumulating. There's also an IS_CHANGED override so the node re-runs on every prompt execution even though nothing about its visible inputs changed.

That's why tail is typed * (any type) and why it looks like it does nothing - it's not data, it's an execution-order marker. You're telling the node "I'm the last thing that runs."

Where it's actually useful

• Comparing two setups: sample with sampler A, note the number, switch to sampler B, note it again. No console archaeology.
• Grid/batch runs where per-iteration cost matters - seeing that one seed takes 4.3s and another 11s tells you your batch is latency-bound somewhere.
• Feeding the number into a filename or a log. Wire execution_time_str into a text save and you've got an automatic benchmark log, which pairs neatly with FRED_Save_Text_File from this same pack.

Honest caveat: this measures total prompt execution, not per-node breakdown. If you need to know which node is the bottleneck, this won't tell you - that's what the console's per-node timings or a profiler are for. It answers "how long does this whole thing take," which is a different and very common question.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Poukpalaova/ComfyUI-FRED-Nodes_v2.git

Restart, or grab "ComfyUI FRED Nodes v2" from ComfyUI Manager. No extra dependencies beyond the pack's base requirements - it's pure stdlib timing.

Gotchas

The timer only means something if this node genuinely runs last. If you hang it off a mid-workflow node, you're timing the partial graph. Also note it prints the elapsed time to the ComfyUI console too, which is a nice bonus for people who like a paper trail. And if you have multiple FRED_ExecutionTime nodes in one graph, only trust the one attached to the final output - the singleton timer means extra copies are mostly redundant.