Grunt watch exhibiting elevated CPU usage during file‑change events

Determine whether the CPU spike observed when grunt watch processes large file trees originates from the gaze library’s polling fallback or from native fs.watch events.

The watch task relies on gaze, which selects fs.watch where available and falls back to periodic polling; on platforms where fs.watch is unreliable (e.g., certain network filesystems or under antivirus interference) the fallback may dominate, but the exact contribution is unclear without internal profiling. Users must rely on external tools to measure watch‑loop overhead, yet the interaction between glob complexity, file count, and interval settings remains uncertain.

What proportion of the watch loop’s CPU time is attributable to gaze polling versus fs.watch callbacks? How can the polling interval be tuned to balance latency and CPU load without introducing missed changes?