[☀️ Google Summer Of Code ] Terminal-Integrated Performance & Memory Investigation Companion

[gsquared94]

Problem Statement

Build a suite of Gemini CLI skills for common investigative workflows — memory dump analysis, profiling, and performance diagnostics — directly within the terminal. Rather than implementing full Debug Adapter Protocol (DAP) integration (which consumes many agent turns for stepping/breakpoints and is often slower than logging-based approaches), this project focuses on areas where LLM + tooling is uniquely powerful: interpreting complex, low-level diagnostic data like memory snapshots, heap profiles, and performance traces that humans historically struggle to parse.

The initial focus is Node.js memory analysis (directly applicable to diagnosing Gemini CLI's own memory bloat and leaks), outputting results in Perfetto trace format so the approach scales to Android and Flutter in the future.

Expected Outcomes

• Automated 3-Snapshot Technique skill: A skill that automatically captures three heap snapshots at defined intervals, diffs them, and identifies leaked objects and their retainer chains using the 3-snapshot technique
• Memory dump analysis tooling: Tools to ingest and summarize Node.js heap snapshots (.heapsnapshot), identifying suspicious growth patterns, large object clusters, and detached DOM nodes
• Perfetto trace integration: Output investigation results in Perfetto-compatible format (ui.perfetto.dev) for visual exploration, with a path to Android/Flutter profiling support
• CLI-based debugger skills: Skills wrapping scriptable debugger CLIs (e.g., GDB's batch/scripting mode, node --inspect + chrome-devtools-protocol) rather than DAP, minimizing agent turns by executing command sequences in bulk
• Performance profiling skills: Skills for common investigative workflows — CPU profiling, performance regression analysis, and binary size/linking analysis — across Node.js and extensible to other ecosystems
• Automated root-cause suggestions: LLM-driven analysis of raw memory/profiling data to surface probable root causes that would be difficult for humans to identify from raw dumps alone

[deadsmash07]

Interesting project. I'm a fourth-year CS student at IIT Delhi (dual degree) and I've been contributing to the repo (env sanitization fix merged in #20514, test coverage issue opened in #20552). I've done kernel-level work (paging subsystems in xv6, network controllers with OpenFlow) and built evaluation pipelines for analyzing model outputs, so the combination of low-level systems diagnostics with LLM-driven analysis here is appealing. My primary interest is the eval-focused project in #23331 but I wanted to flag my interest here as well given the systems overlap.

[Akshitwadhwa]

My approach is to build this as a set of composable CLI skills, where each skill handles a specific investigative workflow (memory, profiling, traces), and the LLM is used only where it adds real value: interpreting complex outputs.

Instead of tightly coupling everything to a debugger protocol, I will rely on scriptable tooling + structured outputs + post-analysis, which is faster, more reliable, and easier to extend.

[Yumin-Sun-00]

Hi, I'm interested in working on this issue as part of getting familiar with the project and potentially contributing to GSoC.

I have experience with observability (Grafana, OpenTelemetry), and I'm particularly interested in performance debugging and root-cause analysis.

Could you please confirm if this issue is still open and suitable for a first contribution?

[Jamijunky]

Does writing "/assign" here assigns me this issue. Lets see. By the way, I’m contributing to this issue as well. Looking forward to learn loads of stuff.

[Jamijunky]

/assign

[gemini-cli]

👋 @Jamijunky, thanks for your interest in this issue! We're reserving self-assignment for issues that have been marked with the help wanted label. Feel free to check out our list of issues that need attention.

[Jamijunky]

😅

[BharathC0]

@bdmorgan Hi, I'm interested in contributing to this project idea for GSoC 2026!

I've gone through the problem statement carefully. A few questions to better understand the scope:

For the 3-Snapshot Technique skill — is the expectation to wrap existing Node.js v8.writeHeapSnapshot() API, or build custom tooling on top of chrome-devtools-protocol?
For Perfetto output — should the skill generate .proto trace format directly, or is a JSON-based perfetto trace format acceptable for the initial implementation?
Is Node.js the only target ecosystem for GSoC scope, with Android/Flutter as post-GSoC extension?

I've set up Gemini CLI locally and am exploring the skills architecture. Looking forward to your guidance!