cv2.getCPUTickCount

Two of these, one on either side of the operation you're curious about, subtract. That's the use case: cv2.getCPUTickCount() reads the CPU's hardware timestamp counter, so a graph can measure how long a branch of itself takes without you reaching for time.time() in a notebook.

No inputs, one INT output. Drop one on the input side of a filter and one on the output side, then feed both into whatever arithmetic you have handy and compare. You get a number, and that number is a real measurement of this run on this machine - which is exactly what the community's "why is my workflow slow" threads usually lack.

Read the number

The value is enormous and unitless. On the machine I'm looking at it's around 2.7e15, which is what a ~3.2 GHz counter reads a few days after boot. There's no frequency constant that comes with it, so you cannot convert ticks to seconds in the graph - the counter's rate is your clock speed, and OpenCV doesn't hand you that as a number you can plug in.

For timing things in your graph properly, use the sibling pair instead:

• cv2.getTickCount() - a monotonic counter that OpenCV does calibrate.
• cv2.getTickFrequency() - ticks per second. On modern builds this comes back as 1000000000, so a tick is a nanosecond and (t1 - t0) / freq is seconds. That's the portable measurement, and it's the same getTickCount/getTickFrequency idiom people already use in OpenCV examples.

So why keep getCPUTickCount at all? It's the cycle-accurate sibling: TSC ticks track the core's clock rather than wall time, which is what you want if you're comparing two code paths' work rather than their latency. For "how long did that blur take", getTickCount is the honest answer.

Precision ceiling worth knowing: ComfyUI passes INTs around as JSON numbers, and JavaScript doubles are exact only up to 2^53 (~9.0e15). These counters sit in the 1e15–1e16 range, so you are within a factor of a few of the point where a tick count starts getting rounded. It won't bite you today on a normal uptime; it's not a counter you want to subtract from in a browser at the far end of the range.

Wiring it

INT out, so anything that eats an integer works - a maths node, a text display, the pack's own array/scalar plumbing. The counter nodes are pure leaves with no inputs, so ComfyUI's caching is happy to compute them once and reuse the result; if you change something upstream and want fresh numbers, make sure the run actually re-executes the branch you're measuring rather than serving the previous result. That caching behaviour is the plumbing layer doing its job, not a bug - it's the same reason a dozen value nodes in one graph don't cost anything.

Install

Manager → search ComfyUI CV, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv
pip install "opencv-contrib-python-headless~=5.0.0.93"

Restart. Python ≥ 3.12 and a recent ComfyUI on the V3 node API. This function has been in OpenCV forever, so there's nothing version-sensitive here and nothing to download.

Where people get burned

• Trying to convert the ticks to seconds. There's no portable divisor. Use getTickCount + getTickFrequency for seconds; use this one for a raw cycle-ish delta.
• Comparing across machines or cores. The TSC isn't a shared clock in any guaranteed way, and frequency behaviour differs. A tick delta is only meaningful within one run of one process.
• Expecting it to be wall time. It isn't - it's a hardware counter, and while the difference is usually tiny it's a real distinction when a run stalls on I/O.