cv2.getTickCount

No inputs, one int out: a timestamp in OpenCV's own tick units. On its own the number is meaningless - it counts from an arbitrary origin, so a big value doesn't mean anything happened. The pair with cv2.getTickFrequency is the whole idea: two tick readings and a division give you elapsed seconds, which is how every OpenCV sample times a block of code.

How it works

cv2.getTickCount() reads the library's high-resolution counter, and cv2.getTickFrequency() says how many of those ticks there are per second. Divide a difference by the frequency and you have seconds:

seconds = (t1 - t0) / freq

The two are guaranteed consistent with each other, which is why you never use one alone. On modern OpenCV builds the counter is backed by a steady clock rather than the old CPU timestamp counter, so the frequency comes back as a round 1e9 and ticks are effectively nanoseconds. Check it rather than assuming - that's literally what the sibling node is for.

Mechanically, this is one line of cv2 wrapped by the pack's generator, like the other ~470 raw wrappers. No image, no array, no state.

What it's good for in a ComfyUI graph

Timing a step. OpenCV-side work in this pack - the heavier filters, grabCut, optical flow, the stitching nodes - can take seconds to minutes on ordinary frames, and "is the slow part the cv2 step or the model?" is a genuine question that costs one restart to get wrong. Two tick readings around a node answer it.

Getting a number out of a graph is the mildly awkward part, and it's the same everywhere in this pack's scalar lane: an int output has nowhere obvious to go. Wire it into Inspect CV Data - its value input takes anything - and send the summary string to core's Preview as Text. If you want to do arithmetic with it, you're into the array lane (CV Array To Numbers, CV Numbers To Array, one-element arrays through cv2's arithmetic wrappers) or a maths node from another pack; this pack gives you the reading, not the subtraction.

Where it misleads

• ComfyUI caches. A node whose inputs haven't changed may not re-execute at all, so a tick reading taken on run 1 can be replayed verbatim on run 2. Two readings are a diagnostic, not a benchmark harness. If you want honest numbers, time the same run twice with a tick node before and after the thing you're measuring, in one execution pass.
• It measures wall time including everything in between. There's no isolation: if a GPU sync happens between your two readings, that's in the number.
• One variable at a time. The standing advice for anything intermittent applies double here - a fixed seed and a single change, or the tick numbers measure your editing rather than the pipeline.

Install

pip install "opencv-contrib-python-headless~=5.0.0.93"

ComfyUI Manager → search ComfyUI CV, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart ComfyUI after. Requires Python ≥ 3.12 and a recent ComfyUI on the V3 node API - this pack generates every node at import time, and on an older ComfyUI it comes up empty rather than failing loudly. Curated against OpenCV 5.0.0.93; the README warns other versions may behave differently.

Two pack-level notes

Order your installs. opencv-python, opencv-python-headless, opencv-contrib-python and opencv-contrib-python-headless all write into the same site-packages/cv2. Install a non-contrib one over the contrib wheel and the contrib submodules are emptied - some of this pack's nodes simply stop appearing. tools/repair_opencv_contrib.py --check diagnoses it; --apply fixes it. There's no install-time guard, so it's on you to notice.

Read the disclaimers. The pack is blunt that it was written with heavy LLM involvement, that the raw wrappers are uncurated, and that updates aren't planned. For a timing getter that's about as low-risk as this pack gets - but it tells you what to expect from the rest of the raw cv2.* lane: one function call, raw result, edge cases are yours.