ln-812-optimization-researcher

Paths: File paths (references/, ../ln-*) are relative to this skill directory.

ln-812-optimization-researcher

Type: L3 Worker Category: 8XX Optimization

Researches competitive benchmarks, industry standards, and solution approaches for bottlenecks identified by the profiler. Generates prioritized hypotheses for the executor.

Overview

| Aspect | Details | |--------|---------| | Input | Performance map from profiler (real measurements: baseline metrics, per-step timing, bottleneck classification, optimization hints) | | Output | Industry benchmarks, solution candidates, prioritized hypotheses (H1..H7) | | Pattern | Research-first: competitors → industry → local codebase → solutions → hypotheses |

Workflow

Phases: Competitive Analysis → Bottleneck-Specific Research → Local Codebase Check → Hypothesis Generation → Research Report

Phase 1: Competitive Analysis

MANDATORY READ: Load references/research_tool_fallback.md for MCP tool priority chain.

Goal

Establish what "good" looks like for this type of operation. Define target metric if user did not provide one.

Research Queries

| Goal | Query Template | Tool | |------|---------------|------| | Industry benchmark | "{domain} API response time benchmark {year}" | WebSearch | | Competitor performance | "{competitor_type} {operation} latency" | WebSearch | | Standard expectations | "acceptable response time for {operation_type}" | WebSearch | | Framework-specific guidance | "{framework} {operation} performance best practices" | Context7 / Ref |

Output

| Field | Description | |-------|-------------| | industry_benchmark | Expected performance range for this operation type | | competitor_approaches | How top systems solve this (2-3 examples) | | recommended_target | Suggested target metric (if user did not specify) | | target_metrics | Per-metric quantitative targets (see below) | | sources | URLs with dates for all findings |

Target Metric Research

For each metric present in performance_map.baseline, research a quantitative target:

| Metric | Query Template | Tool | |--------|---------------|------| | wall_time_ms | "{domain} API response time benchmark {year}" | WebSearch | | cpu_time_ms | "{framework} handler CPU time benchmark" | WebSearch | | memory_peak_mb | "{domain} API memory usage benchmark {year}" | WebSearch | | http_round_trips | "{domain} API call count optimization best practice" | WebSearch | | io_bytes | "{domain} file processing throughput benchmark" | WebSearch |

Output format:

target_metrics:
  wall_time_ms:
    value: 500
    source: "industry benchmark: translation APIs p95 200-500ms"
    confidence: HIGH
  http_round_trips:
    value: 2
    source: "best practice: batch API reduces N calls to 1-2"
    confidence: HIGH
  memory_peak_mb:
    value: 128
    source: "similar workload: 64-128MB typical"
    confidence: MEDIUM

Confidence levels: HIGH = benchmark found with source, MEDIUM = derived from best practices, LOW = estimated from general guidelines. Only include metrics present in the profiler baseline.

Phase 2: Bottleneck-Specific Research

MANDATORY READ: Load [research_query_templates.md](references/research_query_templates.md) for per-type query templates.

Research Strategy

Based on the primary bottleneck type from the profiler:

| Bottleneck Type | Research Focus | |-----------------|---------------| | Architecture | Batching, pipelining, parallelism, DataLoader pattern | | I/O-Network | Connection pooling, HTTP/2, multiplexing, caching | | I/O-DB | Query optimization, indexes, eager loading, bulk operations | | I/O-File | Streaming, async I/O, memory-mapped files | | CPU | Algorithm alternatives, vectorization, caching computation, OSS replacement | | Cache | Eviction policies, cache key design, invalidation strategies, tiered caching, warm-up | | External | Caching layer, circuit breaker, fallback strategies, provider alternatives |

Research Protocol

FOR each top bottleneck (max 3):
  1. Select query templates from research_query_templates.md
  2. Execute research chain: Context7 → Ref → WebSearch (per research_tool_fallback.md)
  3. Collect solution approaches with expected impact
  4. Note technology prerequisites (libraries, infrastructure)

Solution Evaluation

| Field | Description | |-------|-------------| | solution | Name/description of the approach | | source | Where found (URL, docs section) | | expected_impact | Estimated improvement (e.g., "9x reduction for N=9") | | complexity | Low / Medium / High | | prerequisites | What's needed (library, infrastructure, API support) | | feasibility | HIGH / MEDIUM / LOW — based on prerequisites availability |

Phase 3: Local Codebase Check

Before recommending external solutions, check if the codebase already has the capability:

| Check | How | |-------|-----| | Batch/bulk methods on client classes | Grep for batch, bulk, multi in client/service classes | | Cache infrastructure | Grep for redis, memcache, cache, @cached, lru_cache | | Connection pool configuration | Grep for pool_size, max_connections, pool in config | | Async variants | Grep for async_, aio, Async prefix/suffix on methods | | Unused configuration | Read client/service config for batch_size, max_connections params |

Impact on Feasibility

| Finding | Effect | |---------|--------| | Batch API exists, not used | Feasibility = HIGH, Complexity = LOW | | Cache infra exists, not configured for this path | Feasibility = HIGH, Complexity = LOW-MEDIUM | | No existing capability, requires new library | Feasibility = MEDIUM, Complexity = MEDIUM-HIGH | | Requires infrastructure change | Feasibility = LOW, Complexity = HIGH |

Phase 4: Generate Hypotheses (3-7)

Hypothesis Sources (Priority Order)

| Priority | Source | |----------|--------| | 1 | Local codebase check (unused existing capabilities — lowest risk) | | 2 | Research findings (proven patterns from industry) | | 3 | Optimization hints from profiler |

Hypothesis Format

| Field | Description | |-------|-------------| | id | H1, H2, ... H7 | | description | What to change and how | | bottleneck_addressed | Which bottleneck from time map (step reference) | | expected_impact | Estimated improvement % or multiplier | | complexity | Low / Medium / High | | risk | Low / Medium / High | | files_to_modify | List of files that need changes | | dependencies | Other hypotheses this depends on (e.g., "H2 requires H1") | | conflicts_with | Hypotheses that become unnecessary if this one works |

Anti-Bias Checks (mandatory before finalizing)

| Bias | Check | Example | |------|-------|---------| | Removal bias | For each "remove X" hypothesis: generate paired "optimize X" alternative | "remove alignment" → also "optimize alignment config" | | Industry bias | "Industry doesn't use X" ≠ "X not needed for us". Check: does OUR product need it? | "CAT tools skip alignment" but our users need it for quality | | Premature conclusion | "X is slow" ≠ "X is wrong". Slow may mean bad implementation, not wrong approach | 5.9s alignment → maybe wrong algorithm, not wrong feature |

Rule: Every "remove feature" hypothesis MUST have a paired "optimize feature" hypothesis.

Fix Hierarchy (mandatory ordering)

Order hypotheses by fix level. Higher levels ALWAYS tried first:

| Level | Example | Priority | |-------|---------|----------| | 1. Configuration | matching_methods="i", pool_size=10 | Highest — try first | | 2. Infrastructure | Add cache layer, scale service | | | 3. Framework | Use framework feature (batch API, built-in cache) | | | 4. Application code | Refactor algorithm, add optimization | | | 5. Feature removal | Remove functionality | Lowest — last resort only |

Red flag: If highest-priority hypothesis is at level 4-5, re-examine: was a level 1-3 solution missed?