ROCm SamplerCustomAdvanced Benchmark

ROCm SamplerCustomAdvanced Benchmark answers the question everyone asks the first time they install an "optimized" sampler: does it actually help on my machine? It runs the same sampling job twice - once through the stock path, once through the ROCm-tuned path - and hands you the comparison as text. If the pack's tuning is doing anything on your hardware, this is where it shows.

It lives in ROCm Ninodes/Sampling and takes exactly the same five inputs as ROCm SamplerCustomAdvanced: noise, guider, sampler, sigmas, latent_image.

How it works

Phase one runs the stock guider.sample with the cache emptied and a clean slate, timing it and measuring the memory delta. Phase two clears again, applies the pack's ROCm backend settings (and emergency cleanup for high-memory models), then runs the same sample with an enhanced callback and times that too. The outputs are the LATENT from the tuned run - so the node is still functional, not just a lab instrument - plus a BENCHMARK_REPORT string with both timings, the memory deltas, and the speedup percentage.

Wire BENCHMARK_REPORT into a Show Text node to read the verdict.

The inputs that matter

Same stock set as the sampler itself. No optionals, no knobs to misconfigure. The benchmark quality depends entirely on what you feed in: a real guider/sampler/sigmas combo from your actual workflow gives you an answer you can act on; an empty latent with 20 steps gives you a rough feel for raw speed.

Installing it

Standard ROCm Ninodes install - ComfyUI Manager (search rocm-ninodes) or:

cd ComfyUI/custom_nodes
git clone https://github.com/iGavroche/rocm-ninodes.git

then restart; v1.x installs run uv run python tools/upgrade_to_v2.py once. Dependencies: numpy, Pillow, psutil, gguf, safetensors on a ROCm PyTorch build.

The honest version

Two caveats before you leave this in your graph. First, it doubles your run time - every execution samples twice. That's the point of an A/B, but it's a strong argument for removing the node once you have your answer. Second, the "ROCm-optimized" pass is the same guider.sample with backend flags and cleanup around it, not a different algorithm. On a machine where those flags matter - AMD + flow-matching video, LTX 128-channel latents - you'll see a real difference, and it's satisfying to have it in writing. On NVIDIA, or on an easy image workload, the two phases will be within noise, which is itself useful information: it tells you this pack isn't for you. Run it once, read the report, then swap back to the plain ROCm SamplerCustomAdvanced.