ComfyUI Node Runs on cloud

Timer Node KJ

Time any slice of your ComfyUI workflow

By kijai·Created 3 years ago·Updated about 21 hours ago· 2,930
Timer Node KJ
  • any_input
  • timer
  • any_output
  • timer
  • time
mode
nameTimer

When people benchmark ComfyUI, they usually stare at the console and eyeball the total run time. TimerNodeKJ lets you do better than that: it measures a specific section of your graph. Drop one node at the start of the part you care about, another at the end, and it tells you exactly how long that stretch took. If you're trying to figure out whether it's the sampler, the upscaler, or the VAE decode that's eating your time, this is how you find out without guessing.

How it works

It works as a start/stop pair, like a stopwatch you can place anywhere in the flow. You wire something through the node so it executes at a known point - the input is a trigger, same idea as the pack's VRAM debug node - and set the mode. A start timer opens the clock; a stop timer downstream closes it and reports the elapsed time. Because ComfyUI runs nodes in dependency order, placing the start before a stage and the stop after it brackets exactly that stage.

The inputs and outputs

  • any_input - wildcard. Whatever flows through this part of the graph goes in here and comes back out unchanged as any_output. It exists to pin where the timer fires, not to transform anything.
  • mode - start or stop. This is the one setting that matters. Start begins timing, stop ends it and emits the result.
  • name - a label (defaults to "Timer"). Useful when you've got several timers going and want to tell them apart in the output.

There's an optional timer input and a matching timer output - that's the handle that links a start node to its stop node, so you chain the start's timer output into the stop's timer input to connect the pair. The time output (an integer) is the measured duration you actually read.

Why bother

Optimization work lives and dies on knowing where the time goes. Maybe you suspect a heavy custom node is the bottleneck; maybe you're comparing two samplers; maybe you added a detailer pass and want to know what it cost. Wrap the suspect region in a start/stop pair and you get a number instead of a hunch. It's the kind of thing you don't need until you're chasing performance, and then it's exactly what you want.

Installing KJNodes

In ComfyUI Manager, search "KJNodes for ComfyUI" in the Custom Nodes Manager, install, restart. Or by hand: cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt (portable: python_embeded\python.exe -m pip install -r ComfyUI\custom_nodes\ComfyUI-KJNodes\requirements.txt), then restart. Nothing to download - it's a plain utility.

Gotchas

The one that trips everyone: you need a matched pair connected through the timer handle. A lone start node measures nothing, and a stop with no start it can reach has nothing to close. Connect the start's timer output to the stop's timer input.

Also remember what you're actually measuring - wall-clock execution order in the graph, not GPU kernel time to the microsecond. It's plenty precise for "which stage is slow," but don't treat it as a profiler. And caching will lie to you: if a stage is cached from a previous run and doesn't re-execute, the timer around it reports next to nothing, because nothing ran. Change something upstream to force a real run before you trust the number.

CategoryKJNodes/misc

Inputs (4)

NameTypeDefaultDescription
any_input*
modeCOMBO2 options: start, stop
nameSTRINGTimer
timeroptTIMER

Outputs (3)

NameTypeDescription
any_output*
timerTIMER
timeINT