Repository navigation
Enhancement: Implement AST/parsing cache to optimize performance on large repositories #1288
Description
Is your feature request related to a problem? Please describe.
When running CodeGraphContext frequently during active development on a large codebase, the tool recalculates the entire context graph from scratch. Parsing the Abstract Syntax Trees (ASTs) or traversing all files repeatedly creates an unnecessary bottleneck and slows down the developer feedback loop.
Describe the solution you'd like
Introduce a caching mechanism (e.g., storing a .codegraph-cache file in the repository root or system temp directory). The tool should check file modification timestamps or hashes before parsing; if a file hasn't changed, it should load its context from the cache rather than re-parsing it.
Describe alternatives you've considered
Running the tool only on specific sub-directories, but this loses the global context of the codebase.
Additional context
A command-line flag like --clear-cache or --no-cache should be included to allow users to force a fresh run when needed.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
- Status
Activity
Neelr1912 commentedon Jun 19, 2026
/assign gssoc
github-actions commentedon Jun 19, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
valkyrie-nyx commentedon Jun 19, 2026
Hi ,
I'd love to work on this feature under GSSoC.
Frequent full re-parsing can noticeably slow down the development workflow, especially for larger codebases, so adding a caching layer would be a valuable improvement.
My plan is to introduce a cache that stores parsed file context and uses file timestamps or hashes to determine which files actually need to be reprocessed. I'll also add options like
--clear-cacheand--no-cacheso users can easily control the caching behavior when needed.I'll make sure cache invalidation is handled properly and that the global context graph stays accurate across runs.
Please assign this issue to me. Thanks!
codematser69 commentedon Jun 20, 2026
Hello Maintainers,
I would like to work on this issue as part of GSSoC and would appreciate being assigned to it.
Understanding of the Problem
Currently, the tool reparses files and rebuilds the AST graph from scratch on every execution. In large repositories, this creates unnecessary overhead because most files remain unchanged between runs, resulting in longer processing times and a slower developer feedback loop.
Proposed Solution
I plan to implement an AST/parsing cache mechanism that stores parsed results along with file metadata, such as modification timestamps or content hashes.
The implementation will follow these steps:
Expected Impact
I have reviewed the issue and believe this enhancement would be a valuable contribution to the project. I would be excited to work on it as a GSSoC contribution and collaborate with the maintainers to ensure a robust implementation.
Thank you for your consideration.
Shashankss1205 commentedon Oct 15, 2026
Maintenance review — 15 October 2026
Keep caching keyed by file content plus parser/grammar/config versions, with bounded storage and delete/rename invalidation. Full-vs-cached graph equivalence is required; draft #1052's parallel parsing is a separate optimization.