Performance engineer identifying bottlenecks and optimization opportunities.
Quick Start¶
# Select Performance Scenario
/select 06
Architecture¶
The performance workflow uses 4 domain-agnostic components:
| Component | Purpose |
|---|---|
| PerformanceProfiler | Pattern-based bottleneck detection |
| CallGraphAnalyzer | Hotspot identification via call graph in-degree/out-degree |
| ResourceAnalyzer | Resource usage and impact analysis |
| OptimizationAdvisor | Prioritized optimization recommendations |
Specialized handlers in performance_handlers/ provide dedicated analysis for: bottleneck, hotspot, complexity, memory, concurrency, cache, I/O, and inline queries.
Note: All analysis is domain-agnostic. Function names, memory APIs, and language-specific patterns are loaded from the active domain plugin via
DomainRegistry. Examples below use a C codebase as illustration — actual output depends on the analyzed project.
Complexity Analysis¶
Finding Hot Functions¶
The handler queries CPG for functions with high cyclomatic complexity (CFG-based formula: M = E - N + 2) and high in-degree (most called functions):
> Find functions with highest cyclomatic complexity
╭─────────────── Complexity Report ───────────────────────────╮
│ │
│ Top Complex Functions (by cyclomatic complexity): │
│ │
│ # Function Complexity LOC File │
│ ─────────────────────────────────────────────────────────── │
│ 1 process_request 42 287 server.c │
│ 2 dispatch_command 31 195 cmd.c │
│ 3 parse_expression 27 163 parser.c │
│ 4 validate_input 25 312 input.c │
│ 5 build_index 22 178 index.c │
│ │
│ Threshold: high_complexity = 20 │
│ Functions above threshold: 23 │
│ │
╰──────────────────────────────────────────────────────────────╯
Deep Nesting Detection¶
Nesting depth is analyzed through cyclomatic complexity and CFG structure:
> Find functions with deep nesting
╭─────────────── Nesting Analysis ────────────────────────────╮
│ │
│ Functions with high nesting and complexity: │
│ │
│ process_request() complexity: 42 │
│ File: src/server.c:89 │
│ Pattern: Nested loops with conditional branches │
│ │
│ dispatch_command() complexity: 31 │
│ File: src/cmd.c:234 │
│ Pattern: Switch with nested conditions │
│ │
│ Optimization suggestions available for 12 functions │
│ │
╰──────────────────────────────────────────────────────────────╯
Call Graph Analysis¶
Hotspots (In-Degree)¶
The handler identifies hotspot functions using static call graph analysis — counting the number of distinct callers (in-degree) from the edges_call CPG table. This is a structural metric, not dynamic execution profiling:
> Find most called functions
╭─────────────── Call Graph Hotspots ────────────────────────╮
│ │
│ Top Functions by In-Degree (number of callers): │
│ │
│ Function Callers Role │
│ ────────────────────────────────────────────────────────────│
│ validate_input 87 Utility │
│ log_event 64 Logging │
│ alloc_buffer 51 Memory │
│ format_output 43 Formatting │
│ │
│ Functions with high out-degree (calling many others): │
│ process_request 34 callees │
│ dispatch_command 28 callees │
│ │
│ Graph metrics: PageRank, betweenness centrality │
│ │
╰──────────────────────────────────────────────────────────────╯
Critical Paths¶
> Show critical execution paths
╭─────────────── Critical Path Analysis ────────────────────╮
│ │
│ Betweenness centrality identifies bottleneck functions │
│ that appear on many shortest paths in the call graph: │
│ │
│ 1. dispatch_command → process_request → validate_input │
│ 2. main → init_server → load_config │
│ │
│ Functions with high betweenness are architectural │
│ hotspots — optimizing them has the broadest impact. │
│ │
╰──────────────────────────────────────────────────────────────╯
Memory Analysis¶
Memory analysis uses domain plugin functions to find allocation/deallocation patterns. The specific APIs searched depend on the active domain (e.g., malloc/free for C, palloc/pfree for PostgreSQL, new/delete for C++):
> Find memory allocation hotspots
╭─────────────── Memory Allocation Analysis ──────────────────╮
│ │
│ Memory Management Functions Found: 15 │
│ │
│ Function Type File │
│ ────────────────────────────────────────────────────────────│
│ alloc_buffer allocation memory.c │
│ free_buffer deallocation memory.c │
│ resize_pool reallocation pool.c │
│ create_context context context.c │
│ │
│ Analysis includes: │
│ - Allocation functions (domain-specific) │
│ - Deallocation and cleanup │
│ - Context/pool management │
│ - Reallocation patterns │
│ │
╰──────────────────────────────────────────────────────────────╯
Algorithmic Complexity Queries¶
When the query mentions keywords like quadratic, O(n²), nested, or cognitive, the handler routes to the complexity sub-handler. This combines cyclomatic complexity data with memory function analysis from the domain plugin to identify functions likely to exhibit poor scaling:
> Find potential O(n²) patterns
╭─────────────── Complexity-Based Analysis ─────────────────╮
│ │
│ Functions with high complexity (potential scaling issues): │
│ │
│ process_request() complexity: 42 │
│ High cyclomatic complexity suggests nested loops │
│ │
│ build_index() complexity: 22 │
│ Multiple nested iterations detected │
│ │
│ Note: Analysis uses cyclomatic complexity and call graph │
│ metrics as proxies for algorithmic complexity. │
│ Manual review recommended for confirmed O(n²) patterns. │
│ │
╰──────────────────────────────────────────────────────────────╯
Example Questions¶
- “Find functions with high complexity”
- “Show most called functions”
- “Find memory allocation hotspots”
- “What are the hotspot functions by in-degree?”
- “Find functions with deep nesting”
- “Show critical execution paths”
- “Find potential quadratic patterns”
Metrics Reference¶
| Metric | Threshold | Source |
|---|---|---|
| Cyclomatic complexity | > 20 | ThresholdConfig.high_complexity |
| Function size | > 500 lines | ThresholdConfig.loc_very_large |
| In-degree (callers) | > 3 | ThresholdConfig.min_in_degree |
| Impact score | > 0.7 | ThresholdConfig.high_impact |
Related Scenarios¶
- Refactoring - Code improvement
- Tech Debt - Debt indicators
- Debugging - Performance debugging