otimizar-performance

Diagnoses and fixes performance bottlenecks through measurement-first profiling and quantified validation.

Updated Aug 3, 2026
One-click install
npx skills add https://github.com/GuilhermeBrancalhao/ENGINE-CODEX --skill otimizar-performance-guilhermebrancalhao
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: otimizar-performance
Source: https://github.com/GuilhermeBrancalhao/ENGINE-CODEX/tree/main/motores/otimizar-performance
Command: npx skills add https://github.com/GuilhermeBrancalhao/ENGINE-CODEX --skill otimizar-performance-guilhermebrancalhao

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It prevents wasted optimization effort by enforcing a measurement-first discipline: instead of guessing why an application is slow, it establishes a reproducible baseline, identifies the real bottleneck (algorithm, query, I/O, memory, or CPU), and proves the fix with quantified before/after metrics. ## Core Features & Use Cases - Baseline Measurement: Requires concrete numbers (latency, query counts, memory usage) under a defined load before any code change, using profilers, EXPLAIN PLAN, and pg_stat_statements. - Bottleneck Pattern Library: Covers five recurring bottleneck patterns — algorithmic complexity, N+1 queries, I/O and network blocking, memory allocation, and CPU spin loops — each with cause, proof method, and common pitfalls. - Quantified Validation: Delivers a before/after metrics table (P99 latency, queries per request, peak memory) and documents accepted trade-offs so future maintainers understand why the code changed. - Use Case: When a user reports "the endpoint is slow" or "it times out under load", this Skill guides the investigation from baseline measurement through diagnosis to a validated fix, such as reducing 1000 queries per request to 1. ## Quick Start Use the otimizar-performance skill to diagnose why my endpoint takes 5 seconds and validate the fix with before-and-after metrics.

Frequently Asked Questions about otimizar-performance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find the real bottleneck in a slow application?▼

Start by establishing a reproducible baseline with concrete metrics like P99 latency, query counts, and memory usage. Then read profiler output, query logs, and memory profiles to identify which structure consumes the most time, rather than guessing where the problem is.

How to fix N+1 query problems in a database-backed application?▼

Replace per-item queries inside loops with a single batch query or eager loading of associations. Prove the fix with EXPLAIN PLAN and query count logs before and after, showing reduced sequential scans and fewer total queries per request.

Should I rewrite code or change configuration to fix performance issues?▼

Try configuration first: GC tuning flags, transaction isolation levels, cache limits, or indexes often resolve the issue at lower cost and risk. Rewriting code is the last resort, justified only when measurement shows configuration cannot address the bottleneck.

When should I stop optimizing code performance?▼

Stop when latency meets the requirement, when the next bottleneck is external (third-party API, network, infrastructure), or when marginal gains cost more in maintenance than they deliver. Document the achieved gain so future maintainers understand the added complexity.

Why is measuring in production with real users discouraged?▼

Production measurement is discouraged because logging can be destructive, may distort the very metric being read, and trains the application on unrepresentative conditions. Use reproducible test data and controlled load benchmarks instead.