dag-performance-profiler

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.