ProfilerX

First, the thing that'll save you ten minutes of confusion: there is no node to add. ProfilerX has an empty node menu - NODE_CLASS_MAPPINGS is literally {}. You won't find it in the right-click list, you can't wire it into anything, and there's nothing to configure. It's a background profiler plus a dashboard button, and it works the moment the pack is installed. The comfy.icu listing calls it a node because that's how this whole ecosystem gets indexed; in practice it's a service that lives in your top menu bar.

Why would you want it? ComfyUI's own console is useless for "which node is slow." You get a wall of timestamps and no idea what's eating the 40 seconds between prompt and picture. ProfilerX logs execution time, VRAM, and RAM per node, per run, keeps the history, and shows you averages and standard deviation across dozens of runs. That turns "my workflow got slower" from a vibe into a number. If you're on a low-VRAM machine, a workflow developer shipping templates, or a custom-node dev benchmarking, it's genuinely handy.

How it works

The v2.0 rewrite is the interesting part. The original ProfilerX died when ComfyUI moved to async execution, because it worked by wrapping the whole execution pipeline - fragile, breaks on every core update. Version 2 uses ComfyUI's official ProgressHandler API instead. It still needs one small hook: ComfyUI builds a fresh progress registry on every run, which wipes all handlers, so __init__.py patches reset_progress_state to re-inject its handler each time. That's the whole patch - nothing else is touched.

Per node it does three things:

• Times start_handler → finish_handler for execution time.
• Snapshots VRAM and RAM before and after via torch.cuda.memory_allocated (or torch.mps on Apple Silicon) and psutil RSS.
• Detects cache hits for free: a node that gets finish without ever getting start didn't run - it came from cache.

Stats (mean, stddev) are computed with Welford's online algorithm, so the averages stay correct even after 10,000 runs without storing every sample. History lives in data/profiling_history.json inside the pack folder. The only Python dependency is psutil. That's it. No model downloads, no heavy torch reinstall, no version pinning nightmare - genuinely one of the lightest installs in the custom-node ecosystem.

Using it

Run your workflow, then click the chart icon in the top menu bar. The dashboard splits into three views:

• Latest run - per-node time, VRAM/RAM delta, cache hit/miss, with totals.
• Node analytics - averages by node type with stddev columns, time-range filter, sortable. This is where you find the recurring bottleneck instead of a one-off spike.
• Historical trends - workflow-level duration, VRAM peak, and cache rate over 1h/6h/24h/7d/all.

There's a Settings tab for archives (create/load/delete), which you should actually use if your history matters - the file lives inside the pack's own directory, so deleting the custom node takes your data with it. There's also a REST API (/profilerx/stats, /profilerx/archive, …) if you want to script around it.

Install

ComfyUI Manager, search ComfyUI ProfilerX, install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ryanontheinside/ComfyUI_ProfilerX
cd ComfyUI_ProfilerX
pip install -r requirements.txt

Then restart ComfyUI and run one workflow before you go looking for the button.

Gotchas

• Tried it before and it crashed? That was v1. Update to v2 - the README's whole framing is "it works now," and the mechanism check confirms it's a real rewrite, not a version bump.
• Apple Silicon VRAM peaks are best-effort. MPS has no peak-reset API, so the code reports current allocation where CUDA would report a true peak.
• Per-node VRAM deltas are noisy. PyTorch's caching allocator and ComfyUI's async frees mean a node's "VRAM used" can include leftovers from its neighbors. Trust the trends and the big outliers, not the second decimal.
• It's a niche tool, honestly. Crystools is the established perf monitor most people reach for; RyanOnTheInside pitches ProfilerX as a complement, and the history-plus-stddev angle is what it does that Crystools doesn't. If all you need is a live GPU meter, start there. If you want "which node is slow, consistently, across a week of runs," this is the one.

Small pack, real utility, and a rare example of a dev rebuilding a broken node the right way instead of abandoning it.