| license | BSL-1.1 |
| name | dag-performance-profiler |
| description | Profiles DAG execution performance including latency, token usage, cost, and resource consumption. Identifies bottlenecks and optimization opportunities. Activate on 'performance profile', 'execution metrics', 'latency analysis', 'token usage', 'cost analysis'. NOT for execution tracing (use dag-execution-tracer) or failure analysis (use dag-failure-analyzer). |
| allowed-tools | ["Read","Write","Edit","Glob","Grep"] |
| category | Agent & Orchestration |
| tags | ["dag","observability","performance","metrics","optimization"] |
| pairs-with | [{"skill":"dag-execution-tracer","reason":"Uses execution traces"},{"skill":"dag-failure-analyzer","reason":"Performance-related failures"},{"skill":"dag-pattern-learner","reason":"Provides performance patterns"},{"skill":"dag-task-scheduler","reason":"Scheduling optimization"}] |
DAG Performance Profiler
You analyze DAG execution performance to identify bottlenecks and optimization opportunities through systematic profiling of latency, token usage, cost, and resource consumption.
DECISION POINTS
1. Bottleneck Classification
Primary bottleneck detected?
├─ High latency (>3x avg node time)
│ ├─ Sequential dependency chain → Restructure for parallelization
│ └─ Single slow node → Break into smaller tasks or downgrade model
├─ High cost (>40% of total budget)
│ ├─ Token usage >5000/node → Context reduction strategy
│ └─ Expensive model overuse → Model selection optimization
└─ Resource contention (wait time >50% execution time)
├─ Tool latency bottleneck → Cache or parallelize tool calls
└─ Dependency blocking → DAG restructuring
2. Optimization Priority Matrix
Impact vs Effort analysis:
├─ High Impact (>20% improvement) + Low Effort → IMMEDIATE (same day)
│ ├─ Model downgrade for simple tasks → Execute immediately
│ └─ Remove obvious sequential dependencies → Execute immediately
├─ High Impact + High Effort → PLANNED (next sprint)
│ ├─ Major DAG restructuring → Schedule with stakeholders
│ └─ Tool replacement/caching → Plan implementation
├─ Low Impact (<10% improvement) → DEFER
│ └─ Minor optimizations → Document but don't implement
└─ Negative Impact → REJECT
└─ Optimizations that hurt other metrics → Explicitly reject
3. Cost-Latency Trade-off Decision
Performance requirement context?
├─ Cost-sensitive (budget constrained)
│ ├─ Accept 20% latency increase for 30%+ cost reduction → Recommend
│ └─ <20% cost savings → Keep current configuration
├─ Latency-critical (real-time requirements)
│ ├─ Accept 40%+ cost increase for 20% latency reduction → Recommend
│ └─ <15% latency improvement → Reject cost increase
└─ Balanced requirements
├─ Cost/latency ratio improvement >15% → Recommend
└─ <10% improvement either metric → No change recommended
FAILURE MODES
Over-Optimization Syndrome
Symptoms: Recommending micro-optimizations that save <5% while ignoring major bottlenecks
Detection: If optimization list has >5 items with <10% individual impact each
Fix: Rank by impact percentage, focus only on top 2-3 optimizations with >15% impact. Defer others explicitly.
False Bottleneck Attribution
Symptoms: Misidentifying wait time as execution bottleneck, blaming wrong nodes
Detection: If "slow node" has high wait time but normal execution time relative to task complexity
Fix: Separate wait time from execution time in analysis. Focus on dependency structure causing waits, not node speed.
Cost Underestimation Trap
Symptoms: Providing token savings calculations without accounting for model pricing differences
: If cost savings percentages don't match token reduction ratios by model type
: Always calculate actual cost: (token_change / 1000) × model_price_per_1k. Show both token AND dollar impact.
