---
title: "/perf-profiler:profile"
description: "Analyze the codebase for performance bottlenecks, resource inefficiencies, and scalability concerns."
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/profile
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:37:05.411Z
license: CC-BY-4.0
attribution: "/perf-profiler:profile — Claudary (https://claudary.paisolsolutions.com/skills/profile)"
---

# /perf-profiler:profile
Analyze the codebase for performance bottlenecks, resource inefficiencies, and scalability concerns.

## Overview

# /perf-profiler:profile

Analyze the codebase for performance bottlenecks, resource inefficiencies, and scalability concerns.

## Process

1. Identify the project type and performance-critical areas:
   - Read the project structure to understand the architecture (monolith, microservices, SPA, CLI)
   - Identify hot paths: API request handlers, database queries, render cycles, data processing pipelines
   - Check for existing performance tooling (profiler configs, benchmark files, load test scripts)

2. Static analysis for common performance anti-patterns:

### Database & Data Access
- Search for N+1 query patterns: loops that execute individual queries instead of batch operations
- Find missing database indexes by checking query WHERE clauses against schema definitions
- Identify unbounded queries: SELECT without LIMIT, find() without pagination
- Look for ORM eager loading where lazy loading would suffice (and vice versa)
- Check for missing connection pooling configuration

### Memory & Resource Management
- Find large object allocations inside loops or hot paths
- Search for unclosed resources: file handles, database connections, HTTP clients, streams
- Identify memory-heavy data structures where lighter alternatives exist (Map vs Object, Set vs Array for lookups)
- Look for string concatenation in loops instead of StringBuilder/join patterns
- Check for event listener leaks (addEventListener without corresponding removeEventListener)

### Concurrency & Async
- Find synchronous blocking calls on async hot paths (fs.readFileSync in request handlers)
- Identify sequential awaits that could be parallelized with Promise.all or equivalent
- Look for missing caching on repeated expensive computations
- Check for thread pool exhaustion risks (CPU-bound work on the event loop)
- Find busy-wait patterns or polling that could use event-driven approaches

### Frontend Performance (if applicable)
- Search for components re-rendering on every parent render (missing React.memo, useMemo, useCallback)
- Identify large bundle imports where tree-shaking is possible
- Find synchronous layout calculations that trigger forced reflows
- Check for unoptimized images (missing lazy loading, missing dimensions, no srcset)
- Look for blocking scripts in the document head

### Network & I/O
- Find API calls without timeout configuration
- Identify missing retry logic with exponential backoff for external service calls
- Check for uncompressed responses (missing gzip/brotli configuration)
- Look for chatty protocols where batching would reduce round trips

3. Quantify impact where possible:
   - Estimate the number of extra database queries from N+1 patterns (per request)
   - Calculate potential memory savings from data structure changes
   - Estimate latency reduction from parallelizing sequential operations
   - Note the expected bundle size reduction from tree-shaking opportunities

## Output Format

Present findings organized by impact (highest first):

For each finding:
- **Location**: File path and line range
- **Issue**: Clear description of the anti-pattern
- **Impact**: Estimated performance cost (latency, memory, CPU, bandwidth)
- **Fix**: Specific code change or approach to resolve it
- **Priority**: Critical (blocking at current scale) / High (will matter soon) / Medium (optimization opportunity)

End with a summary table: total findings by category and a recommended order of remediation.

## Rules

- Focus on measurable impact, not micro-optimizations
- An optimization that saves 1ms on a path called once per hour is not worth flagging
- Consider the project's scale: what matters for 100 users differs from 100K users
- Suggest profiling tools for findings that need runtime validation
- Do not recommend premature optimization; only flag patterns with clear cost

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/profile) · https://claudary.paisolsolutions.com