Addition of Review Context Cache

[Shashank23123458867504]

I'm planning to add caching for repeated detect_changes/get_review_context computations keyed by repository HEAD and tool parameters to avoid recomputing identical analyses. Does this align with the project's direction, or would you prefer optimization in another area?

[tirth8205]

Thanks for thinking this through, but I measured before answering and I don't think a cache pays for itself right now.

On this repo's own graph, detect_changes_func (code_review_graph/tools/review.py:358) runs in about 100 ms cold and 40 ms warm, and that includes the git subprocess calls plus the SQLite BFS. get_review_context is the same shape. The expensive part of a review session is the model reading the output, not us producing it, and a cache doesn't help with that.

The bigger problem is that HEAD plus params is not a sufficient key. Both tools auto-detect files via get_changed_files and fall back to get_staged_and_unstaged (review.py:58-61, 392-395), which reads staged, unstaged, and untracked files. detect_changes also parses diff ranges from the working tree, and get_review_context reads source snippets straight off disk. So two calls at the same HEAD can legitimately return different results after any edit. On top of that, graph.db is updated incrementally by hooks between calls, so cached impact results would go stale silently even with no user edits.

If someone wants to pursue it anyway, the key would need at minimum: HEAD, a hash of the full diff including staged/unstaged/untracked content, the graph db mtime or a generation counter, schema version, and all params. It would have to be opt-in, bounded in size, and come with tests for the dirty-worktree and incremental-update invalidation cases. That's a lot of machinery to save 40-100 ms, so I'd hold off unless profiling on a very large repo shows a real bottleneck.