Just built a small CLI tool to benchmark plugin performance

I've noticed an increasingly tedious trend in our ecosystem: the relentless, often blind, adoption of plugins and tools based solely on their popularity or feature checklist, with zero regard for their runtime performance overhead. We've all been there—your editor starts to lag, your test suite that used to take 45 seconds now takes 8 minutes, and your CPU fan sounds like it's preparing for liftoff. Invariably, the culprit is a bloated plugin architecture that someone insisted was "the standard."

This is particularly grating in the context of linting and formatting, where we're essentially talking about pure text processing. The difference between a lean, focused tool and a kitchen-sink monolith masquerading as a modular plugin can be staggering. To move the conversation from anecdotal grumbling to something resembling data, I built a small, brutalist CLI benchmarking tool. It's not fancy. It doesn't have a web dashboard. It just runs a target tool against a standardized codebase snapshot a few hundred times and gives you the cold, hard numbers: mean time, memory footprint, and CPU cycles.

The goal here isn't to crown a single "winner," but to inject some much-needed pragmatism into plugin selection. Before you add that 50th VS Code extension or that 12th `pre-commit` hook, maybe consider what it's actually costing you in developer time and machine resources. I ran it against a few usual suspects in the JavaScript/TypeScript formatting and linting space, and the results were... illuminating, if not surprising.

Here's a simplified example of the runner's core logic (the actual tool handles more edge cases and collects system metrics):

```bash
#!/bin/bash
# core_benchmark.sh
WARMUPS=10
RUNS=100
TARGET_FILE="./fixtures/large_source_file.ts"

echo "Benchmarking: $@"
# Warm up
for i in $(seq 1 $WARMUPS); do
$@ $TARGET_FILE > /dev/null 2>&1
done

# Timed runs
total=0
for i in $(seq 1 $RUNS); do
start=$(date +%s%N)
$@ $TARGET_FILE > /dev/null 2>&1
end=$(date +%s%N)
total=$((total + end - start))
done

avg_ms=$((total / RUNS / 1000000))
echo "Average execution time: ${avg_ms}ms"
```

Some preliminary observations from my runs on a decently-sized codebase:
* **Toolchain Bloat:** A popular "all-in-one" linting/formatting setup, configured with a typical rule set, was routinely 3-5x slower than a chain of smaller, single-purpose tools doing equivalent work. The overhead wasn't in the analysis itself, but in the plugin system's bootstrapping and dependency resolution.
* **The Hidden Cost of "Framework" Plugins:** Plugins built for generic test runners or build systems often carry tremendous overhead. A dedicated CLI tool that does one job will almost always outperform a plugin that has to conform to a larger framework's lifecycle and API.
* **Node.js Module Resolution:** This is a silent killer. Tools that trigger a deep module resolution on every execution (common in some ecosystems) add hundreds of milliseconds before they even start working. Pre-bundled or natively compiled tools avoid this tax entirely.

I'm planning to run a more extensive suite, pitting tools like `prettier` vs. `rustfmt`, `eslint` vs. `biome`, and various Git hook implementations against each other. What I'm really interested in, though, are the pain points you've experienced. Which plugins or tool categories have you found to be deceptively heavy? Are there any specific comparisons you'd like to see put under the microscope? Let's build a list and get some real numbers out there.