OpenCV TickMeter vs External Profiler for Primitive-Level Bottleneck Attribution

When profiling an OpenCV image-processing pipeline — decode, resize, color conversion, inference — the documented approach wraps each stage in cv::TickMeter (C++) or cv2.getTickCount() (Python) and runs many iterations after a warm-up pass. This yields reliable per-stage wall times, but it cannot break down time spent inside a single optimized primitive such as resize or GaussianBlur when those functions dispatch to SIMD, OpenCL, or multithreaded backends.

The unresolved decision is whether wall-time measurements alone are sufficient for optimization prioritization, or whether an external profiler (Linux perf, Intel VTune, py-spy) must be combined with TickMeter to attribute cycles inside a primitive. Constraints include: debug vs release build disparity, cv::setNumThreads() and OPENCV_NUM_THREADS altering parallel behavior, first-call warm-up skewing single-run results, and UMat/OpenCL host-device transfer overhead that may shift rather than remove cost.

Specific questions:

1. For a pipeline where one primitive dominates TickMeter time, does adding an external profiler change the optimization target in practice?
2. Is there a portable heuristic to decide when primitive-level attribution is necessary versus when per-stage wall time is actionable?
3. How should measurement methodology differ when the same pipeline runs on CPU-only builds versus OpenCL-enabled builds?