docs/performance/walkthrough-network-rendering-profiling.md

# Performance Profiling: Large Grid Interaction

I have profiled the performance of ExpertAssist using the provided `config_large_grid.json` (114MB grid file) and the contingency `ARGIAL71CANTE`. The results identify two major bottlenecks: extreme backend processing latency and a massive SVG payload that overwhelms the frontend.

## 📊 Profiling Summary (Refined)

| Category | Component / Step | Time (s) | Size (MB) |
| :--- | :--- | :---: | :---: |
| **Initial Load** | Backend API (`getNetworkDiagram`) | 6.22s | **14.1 MB** |
| | Frontend SVG Scaling (`processSvg`) | 0.58s | - |
| | Metadata Indexing (`buildMetadataIndex`) | 0.07s | **10.5 MB** |
| | **DOM Rendering** (`innerHTML_render_n`) | **0.21s** | - |
| **Contingency Select** | Backend Analysis (`run_analysis_step1`) | 18.38s | - |
| | **DOM Rendering** (`innerHTML_render_n-1`) | **0.83s** | - |
| **Grand Total** | **Click to N-1 Visualization** | **~26s** | **~24.6 MB Total** |

## 🔍 Key Findings (Refined)

### 1. The "Big Bang" Rendering
While backend processing is 70% of the total wait time, the **826ms DOM rendering time** for the N-1 state is a critical frontend bottleneck. This is the period where the browser main thread is "locked" while it parses 14MB of SVG markup and calculates the initial layout. During this sub-second window, the UI is completely frozen.

### 2. SVG Scaling Overhead
The `boostSvgForLargeGrid` utility adds about **580ms** to the load time. This function uses `DOMParser` to rebuild the SVG tree in memory, which is expensive for such large files.

### 3. Potential Scaling Bug (NaN Errors)
The console logs revealed **30+ SVG attribute errors** (e.g., `Expected number, "NaN,NaN"`). This suggests that the custom scaling logic in `svgUtils.ts` is encountering unexpected coordinate formats in the large grid SVG, resulting in `NaN` values. This not only causes rendering glitches but can also trigger expensive error-handling paths in the browser.

### 4. Payload Interaction
The interaction lag (zooming/panning) is directly proportional to the **tens of thousands of DOM nodes** created during the 826ms rendering window. Future optimizations should focus on reducing this node count.

## 🚀 Recommendations (Updated)

1.  **Fix NaN Scaling Logic**: Investigate `svgUtils.ts` to ensure coordinate parsing handles all SVG attribute formats (e.g., scientific notation) to prevent `NaN` values.
2.  **Move Scaling to Backend**: Perform the SVG boosting/scaling on the backend or in a Web Worker to keep the main thread free for UI responsiveness.
3.  **Virtualization / Element Pruning**: The most impactful change would be to prune invisible or low-voltage elements from the SVG before it reaches the browser.

### 3. Frontend Optimizations are Active but Overwhelmed
The `usePanZoom` hook and `App.css` already implement advanced optimizations:
- `contain: layout style paint` to isolate the SVG subtree.
- `pointer-events: none` on all SVG children during interaction to skip hit-testing.
- `vector-effect: non-scaling-stroke` to avoid recomputing line widths.
- `requestAnimationFrame` throttling for zoom/pan updates.

Despite these, the absolute volume of SVG data exceeds typical browser performance limits for smooth 60fps interaction.

## 🚀 Recommendations

1.  **SVG Decimation/Pruning**: The backend should filter elements based on voltage levels or "interest zones" before generating the SVG for large grids.
2.  **Streaming / Level-of-Detail (LoD)**: Implementing a tiled or LoD approach for the network diagram would prevent loading the entire grid into the DOM at once.
3.  **Tighter Metadata**: Reducing the 10MB metadata payload by stripping non-essential fields for the visualization would improve frontend responsiveness.
4.  **Asynchronous Analysis**: Providing incremental feedback while `run_analysis_step1` is running (e.g., "Simulating...") would improve the perceived speed.

---
*Profiling performed on 2026-03-30 using `cProfile` and custom timing hooks.*