# C Extension Evaluation: Data-Oriented Python Optimization Pass

## Candidates for Future C Extension Porting

While the current Python optimizations have significantly improved performance, the following components remain candidates for lower-level implementation if project scale increases by an order of magnitude.

### 1. AST Structural Pruning (`src/file_cache.py`)
- **Reason:** Current skeletonization and curated view generation rely on the Python `ast` module and iterative tree traversal.
- **Benefit:** A C-based AST visitor (or tree-sitter integration) would reduce context building time for large codebases.
- **Priority:** Medium

### 2. Large-Scale Graph Operations (`src/dag_engine.py`)
- **Reason:** Although Kahn's algorithm and queue-based propagation are efficient, Python's overhead for object management in graphs with >10,000 nodes could become visible.
- **Benefit:** C++ graph backend would ensure zero-latency orchestration even for massive tracks.
- **Priority:** Low (Current performance is sub-millisecond for hundreds of nodes).

### 3. High-Frequency GUI Data Marshalling (`src/gui_2.py`)
- **Reason:** Preparing complex data structures (e.g., token usage history, metric graphs) for ImGui in the main render loop consumes Python JIT time.
- **Benefit:** Moving data preparation to a background thread or a C buffer would further reduce input lag.
- **Priority:** Low

## Summary
The current optimizations have established a solid "Less Python" foundation. C extensions are not strictly necessary at the current project scale but should be considered if context aggregation or DAG orchestration exceeds 50ms in real-world scenarios.
