Top 10 Performance Skills for AI Coding Agents

This broad web workflow prioritizes real-user experience before selecting a fix. It starts from field signals such as Core Web Vitals, then uses browser performance traces to connect a poor result to a specific resource, rendering task, or interaction. When field data is unavailable, static findings remain hypotheses rather than measured regressions. That distinction helps keep a plausible code smell from being presented as the cause of a user's delay.

After identifying a measured bottleneck, the guide focuses changes on the relevant code or assets and calls for equivalent lab measurements before and after. It treats field verification as pending until enough new user data arrives. The cited budget values are starting guardrails, not universal pass criteria; preserve the product's own targets and representative device, network, and journey conditions. This is the broad starting point for a web performance investigation, not a separate specialist for every frontend framework.

This Go-specific remediation guide begins after measurement identifies a bottleneck. Its method is to define the metric, establish a baseline, diagnose the relevant hot path, make one targeted change, then compare again. The referenced patterns span allocations and memory layout, CPU work, garbage collection, I/O and networking, caching, and algorithmic complexity. It also asks the investigator to rule out external waits first, since a slow database or upstream service will not be fixed by reducing allocations in the caller.

Use it to turn profile or benchmark evidence into a constrained code change, not as permission to tune every plausible hotspot. The examples discuss specific runtime and library behavior, so check the project's Go version, workload, semantic requirements, and lifecycle before adopting one. Numeric examples are not portable results. The source lists benchstat as a dependency and uses an unpinned `@latest` install; review dependency policy before adding it. Keep production profiling and telemetry within the service owner's approval.

This is the measurement lane rather than the remediation catalog. It covers benchmark structure, setup and timing, allocation reporting, pprof and execution traces, statistical comparison with benchstat, compiler diagnostics, and CI regression workflows. The references also discuss noisy benchmark runners and production metrics. Use the narrowest relevant path: a benchmark can compare one operation, a profile can locate work, and a trace can reveal when goroutines wait or the runtime schedules work.

Treat source claims as material to verify, not commands to copy blindly. A `_bench_test.go` file does not prevent ordinary tests from running with `go test -bench=.`; add an appropriate test-name filter such as `-run='^$'` when the intent is benchmarks only. `b.Elapsed()` is valid after `b.Loop()` finishes; do not copy the source's restriction to use it only inside the loop. Record Go version, CPU, workload, and conditions, collect repeated samples, and do not infer significance from a single run. Its `cob` setup uses `git reset` and is described for CI, so inspect it before any use.

This Python workflow pairs profiling with practical optimization choices. It uses built-in cProfile and pstats for an initial view, then describes optional line-level or memory tools when the question needs finer attribution. The guidance covers Python-specific costs in data structures, iteration, vectorization, concurrency, I/O, caching, and database calls. Begin with a representative input and the symptom that matters, because a faster micro-operation does not necessarily reduce request latency or peak memory for the real workload.

Use profile evidence to select a targeted change and keep the original behavior intact. Vectorized operations can add conversion costs, caches need correct invalidation, and parallel execution can increase memory or coordination overhead. The examples are techniques to test, not proof of a speedup. Built-in tooling is the lower-friction start; installing optional profilers or attaching to a production process needs project and operator approval. Compare equivalent runs with the same data shape and environment before reporting a result.

This focused browser workflow investigates motion that stutters, scrolls unevenly, or causes avoidable rendering work. It directs attention to layout thrashing, compositor-friendly properties, scroll-linked effects, blur, and how animation work is scheduled. For a concrete interaction, inspect whether scripts repeatedly read and write layout, whether a scroll handler polls more often than needed, or whether an animation keeps requesting frames after its useful work has ended.

The guidance helps select a technique that fits the interaction, including batching DOM reads and writes, using browser scroll or visibility APIs where appropriate, and treating layer promotion as a measured option. It does not make a layer or compositor property a guarantee of smoother frames. Validate the result in the actual browser and on representative devices, because memory pressure, raster cost, refresh rate, and browser heuristics can change the outcome. Choose the broader web card for loading and field metrics instead.

This audit focuses on SwiftUI's update and rendering behavior. It begins by recording the interaction, device, operating-system version, and build conditions, then examines view identity, state dependencies, and update fanout for plausible causes. If code review is insufficient, the workflow calls for a user-run Instruments profile of the same interaction. Keeping a clear separation between code suspicion and trace evidence makes the resulting report more useful than a list of stylistic recommendations.

The supporting materials cover profiling intake, report structure, common code smells, and Apple's performance guidance. Apply a proposed change against the deployment target and the actual device conditions. A view pattern that looks expensive is not automatically the cause of a runtime problem, and precomputing data can introduce stale state when invalidation is incomplete. This card is specific to SwiftUI; it is not a general iOS profiling recipe and does not run Instruments or certify performance on the user's behalf.

This guide is a broad Postgres rulebook, not merely a query profiler. It applies to schema and type choices, migrations, row-level security, indexes, triggers, database functions, queues, vector search, and operational concerns. For performance work it connects query shapes with EXPLAIN plans, indexes, connection limits, pooling, prepared statements, and lock behavior. Its references cover missing, composite, partial, and index-type decisions, plus monitoring with EXPLAIN ANALYZE and pg_stat_statements.

Use the guidance before changing database structures or SQL, then check actual provider behavior, version, schema, workload, access policy, write cost, and rollback path. Indexes can improve reads while adding write and storage cost, and a general pattern is not a substitute for a representative plan. `EXPLAIN ANALYZE` executes the statement, so understand side effects and resource cost before running it, especially on production data. Open the upstream reference for the specific query, index, connection, or RLS question you are investigating.

This specialist card covers PixiJS v8 rendering concerns such as texture and object lifecycle, batching, culling, garbage collection, preparation, dynamic text, and GPU resource tradeoffs. Its value is in engine-specific guidance that a general browser profile may not explain. Start from the observed frame-time or memory symptom, then inspect the relevant scene and API path rather than applying every pooling, caching, or teardown pattern to every application.

The examples require qualification against the installed PixiJS release and the app's ownership model. `releaseGlobalResources` is an available API, not a mandatory teardown step when resources are shared; same-value text writes may be no-ops; alternating object types do not imply a fixed draw count. One preparation example does not establish that its texture is attached or eliminate a first-frame hitch. Validate actual rendering on representative devices, and do not treat sample counts or cache toggles as universal performance laws.

This workflow starts with V8 `.heapsnapshot` files already supplied or captured through another process. Its helpers parse snapshots, compare object groups, and trace reverse retainers while the investigator records what changed. It does not capture a snapshot, establish that a leak exists, or provide a universal JavaScript memory analyzer. The Microsoft examples illustrate VS Code services and object names, so treat them as product-specific context rather than V8 invariants.

The parser eagerly reads and expands the complete snapshot, so memory use can grow substantially; the streaming helper supplies parsing primitives, not a complete streaming comparison or retainer engine. Retainer searches are bounded by depth and attempt limits, exclude weak edges, and stop at synthetic nodes, so an endpoint or missing path is not proof of a true root or absence of a leak. Before-and-after object-ID matching is meaningful only for snapshots from the same V8 isolate when IDs persist. Comparison reports counts and self-size, not dominator or retained-size analysis. Snapshot strings and findings can contain sensitive application data; keep artifacts local, avoid raw uploads or commits, and verify helper paths in the installed layout before use.

This guide helps select and run a .NET diagnostic collection workflow based on the symptom, runtime version, operating system, container or Kubernetes shape, privilege, and reproduction context. It explains tradeoffs among tools such as dotnet-trace, PerfView, perfcollect, and dotnet-monitor, then emphasizes recording the target process and the collection window. The intended output is a diagnostic artifact plus enough environment and command context for a separate analysis step.

Collection is not analysis, benchmarking, or proof that an artifact is complete or representative. Some paths are privileged: Linux machine-wide collection can require root and kernel support, container perfcollect examples request broad capabilities, and Windows PerfView may require administrator rights. Production monitoring should use authentication and restricted access, and diagnostic files may contain sensitive symbols or request context. Obtain incident-owner authorization, bound overhead and duration, verify the PID, choose a protected local destination, and define stop and cleanup steps before capture.