ComfyUI Node

TimerStart

How to actually time part of your workflow

By Shannooty·Created 2 years ago·Updated 2 years ago· 4
TimerStart
  • value
  • *

If you've ever wanted to know exactly how long one stage of your workflow takes - not the whole queue, just "how long did that upscale pass actually cost me" - you've probably done what everyone does: eyeball the console, or just remember roughly. ComfyUI doesn't give you a stopwatch for free. TimerStart, from the tiny ComfyUI Timer Nodes pack, is the start button for one.

It does exactly one thing: the moment it executes, it resets a global timer. That's it. It's not measuring anything on its own - it's just marking "the clock starts here." Its partner node, TimerStringConcat, is the one that actually reads the elapsed time back out later in the graph and stamps it onto a string.

The mechanism, and why it looks the way it does

TimerStart takes a single required input called value, typed as * - ComfyUI's wildcard type, meaning it'll accept literally anything you plug into it: a string, an image, a latent, a conditioning object, whatever. It passes that value straight back out unchanged as its output.

That passthrough design isn't decoration, it's the whole point. ComfyUI schedules nodes by the dependency graph, not by where you dropped them on the canvas - a node just sitting off to the side isn't guaranteed to run "before" anything just because it looks earlier visually. So to actually pin TimerStart to a specific point in execution order, you route real data through it: take whatever you want to bracket the timing around, feed it into value, and send the output onward exactly as if TimerStart weren't there. Wiring it into the chain is what forces the scheduler to run it, and reset the clock, at that point - not its position on screen. Using a wildcard type for this is the same trick reroute-style utility nodes lean on across the ecosystem, so it can slot into almost any connection without ComfyUI complaining about a type mismatch.

  • Input: value (any type) - whatever you're routing through to force the timing point.
  • Output: the same value, unchanged - wire it onward to wherever it was originally headed.

Installing it

Two ways, both from the README:

  1. ComfyUI Manager - search for "ComfyUI Timer Nodes" in the manager UI and install.
  2. Manual - from your ComfyUI install, cd custom_nodes && git clone https://github.com/Shannooty/ComfyUI-Timer-Nodes, then restart ComfyUI.

There's nothing else to it. No requirements.txt, no models to fetch, no API keys. That's genuinely refreshing in this ecosystem - the most common complaint about custom nodes generally is dependency conflicts, where two packs want incompatible versions of the same pip package and something breaks. A pack this small, with no listed dependencies, just isn't going to be the thing that wedges your Python environment.

Where people get tripped up

It's a single global timer, not one per node. The README calls it "the global timer" for a reason - there's one clock, and any TimerStart anywhere in your graph resets it. If you drop a second TimerStart hoping to time two separate stages independently, you'll just overwrite the same clock the second one fires, and your first measurement is gone. Keep it to one start point and one read point per thing you're actually trying to measure.

If it doesn't show up after install, it's a plain missing-node problem, not anything specific to this pack - confirm you restarted ComfyUI rather than just refreshing the browser tab, and check the startup console log for an import error. Since this pack is labeled "WIP" by its own author and has no dependencies to conflict with, an import failure here is unusual, but it's the first thing to rule out.

Don't expect a profiler. This won't break down time per node or show you a flame graph - it marks one moment. If you want more granular, per-sampler timing without wiring anything yourself, there are other small community nodes built specifically for that (a KSampler-focused timer node is one you'll come across), but that's a different tool for a different job. TimerStart is deliberately the simplest version of "start the clock here," and for a lot of debugging that's genuinely all you need.

CategoryStart Timer

Inputs (1)

NameTypeDefaultDescription
value*

Outputs (1)

NameTypeDescription
**