SimpleTimerEnd

SimpleTimerEnd is the half of this pack's stopwatch that does the math and shows you the answer. You run SimpleTimerStart somewhere upstream to stamp a start time, and this node, sitting at the point you care about, computes how long the stretch took and hands you the numbers - plus your image back, untouched. It's the node you'll actually look at, so let's talk about what comes out of it.

What it gives you

The node takes one required input and returns three outputs:

• image - required, type IMAGE. This is the quirk to know about: the node needs an image to pass through. It reads the batch size off the image's shape (the first dimension) so it can divide timing per image, and it passes the image straight back out. In practice you slot it right before your Preview Image or Save Image node. It also means this timer is for timing image-producing runs, not text-only branches.
• image - the same image, passed through untouched, so the node doesn't break your pipeline.
• single_time_str - a string like 2.31 seconds. This is per-image time: the elapsed time for the current execution divided by the batch size.
• total_time_str - the total elapsed time from when SimpleTimerStart fired until this node ran, across the whole batch.

A widget on the node shows the single-execution time in the UI (it's a read-only display, updated after each run), and both times get printed to the console. The README is explicit: the widget shows only the per-image number - grab total_time_str if you want the batch-wide figure.

How the timing works

SimpleTimerStart writes a timestamp to a module global; SimpleTimerEnd reads it, compares it against time.time(), and keeps track of whether this is a fresh start (new batch → lap time equals total time) or a continuing run (it measures from the last time it ran, giving you per-iteration time in a batch). Batch size comes off the image tensor's shape[0], and single time is lap time divided by that batch size. Like its Start counterpart, it uses the float("NaN") IS_CHANGED trick so it always runs - a timer that got cached would just be a wrong number.

Placement

• Not connected to anything upstream: you get the time from workflow start to this node.
• Wired into the middle of a graph: the time covers only the segment from that point to End. The README's example is timing one stretch of a pipeline rather than the whole run.

Gotchas

• One shared clock, remember. Start and End both read the same global, so a second Start node anywhere in the workflow will stomp on your timing. One stopwatch per workflow.
• It wants an image, full stop. There's no way around the IMAGE input - the author built it around reading the batch size off the image tensor. If you're timing something that never produces an image, this isn't the timer for it.
• Strings, not numbers. Both times come out as formatted strings (2.31 seconds), which is great for display but means you can't do arithmetic on them without converting. Fine for a glance; a real benchmark rig wants numbers.

Installation

Same story as the rest of the pack - zero dependencies, no downloads. Through ComfyUI Manager (search ComfyUI-Text-Utils-sp) or:

cd ComfyUI/custom_nodes
git clone https://github.com/sp8999/ComfyUI-Text-Utils-sp.git

Restart ComfyUI, and both timer nodes are in the text_utils_sp category. The pack's README flags that it's tuned for the Nodes 2.0 frontend; on the older v1 renderer everything still works, but the display widget can render at the wrong size.