# Performance-Focused Code Review Performs comprehensive performance analysis covering database optimization, backend efficiency, frontend rendering, network optimization, and scalability. ## Parameters **Received from router**: `$ARGUMENTS` (after removing 'performance' operation) Expected format: `scope:"review-scope" [depth:"quick|standard|deep"]` ## Workflow ### 1. Parse Parameters Extract from $ARGUMENTS: - **scope**: What to review (required) - API endpoints, database layer, frontend components, entire app - **depth**: Performance analysis thoroughness (default: "standard") ### 2. Gather Context **Understand Performance Baseline**: ```bash # Check project structure and tech stack ls -la cat package.json 2>/dev/null || cat requirements.txt 2>/dev/null # Identify performance-critical files find . -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" | xargs grep -l "query\|fetch\|map\|filter\|useEffect\|useState" | head -20 # Check for existing performance monitoring grep -r "performance\|timing\|profil\|benchmark" --include="*.ts" --include="*.js" | head -10 # Look for database queries grep -r "SELECT\|INSERT\|UPDATE\|DELETE\|query\|execute" --include="*.ts" --include="*.js" --include="*.py" | head -15 # Check bundle configuration ls -la | grep -E "webpack|vite|rollup|esbuild" ``` ### 3. Database Performance Review **Query Optimization**: - [ ] No N+1 query problems - [ ] Efficient joins (avoid Cartesian products) - [ ] Indexes on frequently queried columns - [ ] Covering indexes for common queries - [ ] Query plans analyzed (EXPLAIN ANALYZE) - [ ] Avoid SELECT * (select only needed columns) - [ ] Limit result sets appropriately **Connection Management**: - [ ] Connection pooling configured - [ ] Pool size appropriate for load - [ ] Connections properly released - [ ] Connection timeouts configured - [ ] No connection leaks **Transaction Management**: - [ ] Transactions scoped appropriately (not too large) - [ ] Read vs write transactions differentiated - [ ] Transaction isolation level appropriate - [ ] Deadlock handling implemented - [ ] Long-running transactions avoided **Data Access Patterns**: - [ ] Pagination for large datasets - [ ] Cursor-based pagination for large tables - [ ] Batch operations where possible - [ ] Bulk inserts instead of individual - [ ] Proper use of indexes - [ ] Denormalization where appropriate for reads **Caching Strategy**: - [ ] Query result caching for expensive queries - [ ] Cache invalidation strategy clear - [ ] Redis/Memcached for distributed caching - [ ] Application-level caching appropriate - [ ] Cache hit rate monitored **Code Examples - Database Performance**: ```typescript // ❌ BAD: N+1 query problem const users = await User.findAll(); for (const user of users) { user.posts = await Post.findAll({ where: { userId: user.id } }); user.comments = await Comment.findAll({ where: { userId: user.id } }); } // ✅ GOOD: Eager loading with includes const users = await User.findAll({ include: [ { model: Post }, { model: Comment } ] }); // ✅ BETTER: Only load what's needed const users = await User.findAll({ attributes: ['id', 'name', 'email'], // Don't SELECT * include: [ { model: Post, attributes: ['id', 'title', 'createdAt'], limit: 5 // Only recent posts } ] }); ``` ```typescript // ❌ BAD: Loading all records without pagination const allUsers = await User.findAll(); // Could be millions of records! // ✅ GOOD: Pagination const page = parseInt(req.query.page) || 1; const limit = 20; const offset = (page - 1) * limit; const { rows: users, count } = await User.findAndCountAll({ limit, offset, order: [['createdAt', 'DESC']] }); res.json({ users, pagination: { page, limit, total: count, pages: Math.ceil(count / limit) } }); ``` ```typescript // ❌ BAD: Individual inserts for (const item of items) { await Item.create(item); // Each is a separate query! } // ✅ GOOD: Bulk insert await Item.bulkCreate(items); ``` ```sql -- ❌ BAD: Missing index on frequently queried column SELECT * FROM orders WHERE user_id = 123 AND status = 'pending'; -- This could be slow without an index! -- ✅ GOOD: Add composite index CREATE INDEX idx_orders_user_status ON orders(user_id, status); ``` ### 4. Backend Performance Review **Algorithm Efficiency**: - [ ] Time complexity analyzed (avoid O(n²) where possible) - [ ] Space complexity considered - [ ] Efficient data structures used (Map vs Array for lookups) - [ ] Sorting algorithms appropriate for data size - [ ] Search algorithms optimized - [ ] Recursion depth manageable (avoid stack overflow) **Async Operations**: - [ ] Async/await used properly - [ ] No blocking operations on event loop - [ ] Parallel execution where possible (Promise.all) - [ ] Proper error handling in async code - [ ] Timeouts on external calls - [ ] Avoid awaiting in loops (use Promise.all) **Caching Strategy**: - [ ] In-memory caching for frequently accessed data - [ ] Distributed caching (Redis) for scalability - [ ] Cache TTL appropriate - [ ] Cache warming strategy - [ ] Cache invalidation correct - [ ] Memoization for expensive calculations **Resource Management**: - [ ] Memory leaks prevented (event listeners cleaned up) - [ ] File handles closed properly - [ ] Streams used for large files - [ ] Buffer sizes appropriate - [ ] Garbage collection friendly code - [ ] Object pooling for frequently created objects **Rate Limiting & Throttling**: - [ ] Rate limiting on API endpoints - [ ] Exponential backoff for retries - [ ] Circuit breakers for external services - [ ] Request queuing for overload - [ ] Graceful degradation under load **Code Examples - Backend Performance**: ```typescript // ❌ BAD: O(n²) complexity - nested loops function findDuplicates(users) { const duplicates = []; for (let i = 0; i < users.length; i++) { for (let j = i + 1; j < users.length; j++) { if (users[i].email === users[j].email) { duplicates.push(users[i]); } } } return duplicates; } // ✅ GOOD: O(n) complexity - using Map function findDuplicates(users) { const seen = new Map(); const duplicates = []; for (const user of users) { if (seen.has(user.email)) { duplicates.push(user); } else { seen.set(user.email, user); } } return duplicates; } ``` ```typescript // ❌ BAD: Sequential async operations async function getUserData(userId) { const user = await fetchUser(userId); const posts = await fetchPosts(userId); const comments = await fetchComments(userId); return { user, posts, comments }; } // ✅ GOOD: Parallel async operations async function getUserData(userId) { const [user, posts, comments] = await Promise.all([ fetchUser(userId), fetchPosts(userId), fetchComments(userId) ]); return { user, posts, comments }; } ``` ```typescript // ❌ BAD: Awaiting in loop async function processUsers(userIds) { const results = []; for (const id of userIds) { const result = await processUser(id); // Sequential! results.push(result); } return results; } // ✅ GOOD: Parallel processing with Promise.all async function processUsers(userIds) { return Promise.all(userIds.map(id => processUser(id))); } // ✅ BETTER: Parallel with concurrency limit async function processUsers(userIds) { const concurrency = 5; const results = []; for (let i = 0; i < userIds.length; i += concurrency) { const batch = userIds.slice(i, i + concurrency); const batchResults = await Promise.all(batch.map(id => processUser(id))); results.push(...batchResults); } return results; } ``` ```typescript // ❌ BAD: No caching for expensive operation function fibonacci(n) { if (n <= 1) return n; return fibonacci(n - 1) + fibonacci(n - 2); // Recalculates same values! } // ✅ GOOD: Memoization const fibCache = new Map(); function fibonacci(n) { if (n <= 1) return n; if (fibCache.has(n)) return fibCache.get(n); const result = fibonacci(n - 1) + fibonacci(n - 2); fibCache.set(n, result); return result; } // ✅ BETTER: Iterative approach (faster) function fibonacci(n) { if (n <= 1) return n; let prev = 0, curr = 1; for (let i = 2; i <= n; i++) { [prev, curr] = [curr, prev + curr]; } return curr; } ``` ### 5. Frontend Performance Review **React Component Optimization**: - [ ] Components memoized where appropriate (React.memo) - [ ] useMemo for expensive calculations - [ ] useCallback for function props - [ ] Unnecessary re-renders prevented - [ ] Proper dependency arrays in hooks - [ ] Key props correct for lists - [ ] Code splitting at route level - [ ] Lazy loading for heavy components **List Rendering**: - [ ] Large lists virtualized (react-window, react-virtualized) - [ ] Pagination for very large datasets - [ ] Infinite scroll implemented efficiently - [ ] Window recycling for scrolling performance - [ ] Avoid rendering off-screen items **Image Optimization**: - [ ] Images properly sized (responsive images) - [ ] Lazy loading implemented - [ ] Modern formats used (WebP, AVIF) - [ ] Image compression applied - [ ] Srcset for different screen sizes - [ ] Loading placeholder or skeleton **Bundle Optimization**: - [ ] Code splitting implemented - [ ] Tree shaking enabled - [ ] Dead code eliminated - [ ] Dynamic imports for large libraries - [ ] Bundle size analyzed (webpack-bundle-analyzer) - [ ] Moment.js replaced with date-fns or dayjs - [ ] Lodash imports optimized (import specific functions) **State Management**: - [ ] State normalized (avoid nested updates) - [ ] Global state minimized - [ ] Computed values memoized - [ ] State updates batched - [ ] Context splits prevent unnecessary re-renders - [ ] Use of local state preferred over global **Web Vitals Optimization**: - [ ] Largest Contentful Paint (LCP) < 2.5s - [ ] First Input Delay (FID) < 100ms - [ ] Cumulative Layout Shift (CLS) < 0.1 - [ ] Time to Interactive (TTI) optimized - [ ] First Contentful Paint (FCP) optimized **Code Examples - Frontend Performance**: ```typescript // ❌ BAD: Unnecessary re-renders function UserList({ users, onDelete }) { return users.map(user => ( onDelete(user.id)} // New function every render! /> )); } // ✅ GOOD: Memoized components const UserCard = React.memo(({ user, onDelete }) => (
onDelete(user.id)}> {user.name}
)); function UserList({ users, onDelete }) { return users.map(user => ( )); } ``` ```typescript // ❌ BAD: Expensive calculation on every render function ProductList({ products }) { const sortedProducts = products .sort((a, b) => b.rating - a.rating) .slice(0, 10); // Recalculated every render! return
{sortedProducts.map(p => )}
; } // ✅ GOOD: Memoized calculation function ProductList({ products }) { const sortedProducts = useMemo(() => products .sort((a, b) => b.rating - a.rating) .slice(0, 10), [products] // Only recalculate when products change ); return
{sortedProducts.map(p => )}
; } ``` ```typescript // ❌ BAD: No virtualization for large list function MessageList({ messages }) { return (
{messages.map(msg => ( ))}
); // Renders ALL messages, even off-screen! } // ✅ GOOD: Virtualized list import { FixedSizeList } from 'react-window'; function MessageList({ messages }) { const Row = ({ index, style }) => (
); return ( {Row} ); // Only renders visible items! } ``` ```typescript // ❌ BAD: Entire library imported import moment from 'moment'; // Imports entire 70KB library! // ✅ GOOD: Lightweight alternative import { format } from 'date-fns'; // Tree-shakeable, smaller // ❌ BAD: Lodash imported entirely import _ from 'lodash'; // ✅ GOOD: Specific imports import debounce from 'lodash/debounce'; import throttle from 'lodash/throttle'; ``` ### 6. Network Performance Review **API Optimization**: - [ ] API calls minimized - [ ] GraphQL for flexible data fetching - [ ] Batch API requests where possible - [ ] Debouncing for search/autocomplete - [ ] Prefetching for predictable navigation - [ ] Optimistic updates for better UX - [ ] Request deduplication **Caching & CDN**: - [ ] HTTP caching headers configured - [ ] Cache-Control directives appropriate - [ ] ETag for conditional requests - [ ] Service Worker for offline caching - [ ] CDN for static assets - [ ] Edge caching where applicable **Compression**: - [ ] Gzip or Brotli compression enabled - [ ] Appropriate compression levels - [ ] Assets minified - [ ] JSON responses compressed **Resource Loading**: - [ ] Critical CSS inlined - [ ] Non-critical CSS loaded async - [ ] JavaScript loaded with async/defer - [ ] DNS prefetch for external domains - [ ] Preload for critical resources - [ ] Preconnect for required origins **Code Examples - Network Performance**: ```typescript // ❌ BAD: No debouncing for search function SearchBox() { const [query, setQuery] = useState(''); const handleChange = async (e) => { setQuery(e.target.value); await fetchResults(e.target.value); // API call on every keystroke! }; return ; } // ✅ GOOD: Debounced search import { debounce } from 'lodash'; function SearchBox() { const [query, setQuery] = useState(''); const fetchResultsDebounced = useMemo( () => debounce((q) => fetchResults(q), 300), [] ); const handleChange = (e) => { setQuery(e.target.value); fetchResultsDebounced(e.target.value); }; return ; } ``` ```typescript // ❌ BAD: Multiple API calls const user = await fetch('/api/user/123').then(r => r.json()); const posts = await fetch('/api/user/123/posts').then(r => r.json()); const followers = await fetch('/api/user/123/followers').then(r => r.json()); // ✅ GOOD: Single API call with all data const userData = await fetch('/api/user/123?include=posts,followers') .then(r => r.json()); // ✅ BETTER: GraphQL for flexible data fetching const userData = await graphqlClient.query({ query: gql` query GetUser($id: ID!) { user(id: $id) { name email posts(limit: 10) { title } followers(limit: 5) { name } } } `, variables: { id: '123' } }); ``` ### 7. Performance Monitoring & Profiling **Monitoring Tools**: ```bash # Check bundle size npm run build ls -lh dist/ # Check output sizes # Analyze bundle composition npm install --save-dev webpack-bundle-analyzer # Add to webpack config and analyze # Run Lighthouse audit npx lighthouse https://your-site.com --view # Check Core Web Vitals # Use Chrome DevTools -> Performance # Use Lighthouse or WebPageTest ``` **Performance Metrics**: - [ ] Response time monitoring - [ ] Database query times logged - [ ] API endpoint performance tracked - [ ] Error rates monitored - [ ] Memory usage tracked - [ ] CPU usage monitored **Profiling**: - [ ] Node.js profiling for CPU hotspots - [ ] Memory profiling for leaks - [ ] Chrome DevTools performance profiling - [ ] React DevTools Profiler used ### 8. Scalability Review **Horizontal Scalability**: - [ ] Stateless application design - [ ] Session data in external store (Redis) - [ ] No local file system dependencies - [ ] Load balancer compatible - [ ] Health check endpoints **Vertical Scalability**: - [ ] Memory usage efficient - [ ] CPU usage optimized - [ ] Can handle increased load per instance **Database Scalability**: - [ ] Read replicas for read-heavy loads - [ ] Write scaling strategy (sharding, partitioning) - [ ] Connection pooling configured - [ ] Query performance at scale considered **Caching for Scale**: - [ ] Distributed caching (Redis cluster) - [ ] Cache warming strategy - [ ] Cache hit rate optimization - [ ] Cache invalidation across instances ## Review Depth Implementation **Quick Depth** (10-15 min): - Focus on obvious performance issues - Check for N+1 queries - Review large data fetching without pagination - Check bundle size - Identify blocking operations **Standard Depth** (30-40 min): - All performance categories reviewed - Database query analysis - Frontend rendering optimization - Network request analysis - Caching strategy review - Basic profiling recommendations **Deep Depth** (60-90+ min): - Comprehensive performance audit - Detailed query plan analysis - Algorithm complexity review - Memory profiling - Complete bundle analysis - Load testing recommendations - Scalability assessment - Performance monitoring setup ## Output Format ```markdown # Performance Review: [Scope] ## Executive Summary **Reviewed**: [What was reviewed] **Depth**: [Quick|Standard|Deep] **Performance Rating**: [Excellent|Good|Needs Optimization|Critical Issues] ### Overall Performance Assessment **[Optimized|Acceptable|Needs Improvement|Poor]** [Brief explanation] ### Key Performance Metrics - **Average Response Time**: [Xms] - **Database Query Time**: [Xms] - **Bundle Size**: [XKB] - **Largest Contentful Paint**: [Xs] - **Time to Interactive**: [Xs] ### Priority Actions 1. [Critical performance fix 1] 2. [Critical performance fix 2] --- ## Critical Performance Issues 🚨 ### [Issue 1 Title] **File**: `path/to/file.ts:42` **Category**: Database|Backend|Frontend|Network **Impact**: [Severe slowdown, timeout, memory leak, etc.] **Current Performance**: [Xms, XKB, etc.] **Expected Performance**: [Target] **Root Cause**: [Why this is slow] **Optimization**: [Specific fix] ```typescript // Current code (slow) [slow code] // Optimized implementation [fast code] // Performance improvement: [X% faster, XKB smaller, etc.] ``` [Repeat for each critical issue] --- ## High Impact Optimizations ⚠️ [Similar format for high impact issues] --- ## Medium Impact Optimizations ℹ️ [Similar format for medium impact issues] --- ## Low Impact Optimizations 💡 [Similar format for low impact issues] --- ## Performance Strengths ✅ - ✅ [Optimization already in place] - ✅ [Good performance practice] --- ## Detailed Performance Analysis ### 🗄️ Database Performance **Query Performance**: - Average query time: [Xms] - Slowest queries: [List with times] - N+1 queries found: [Count and locations] - Missing indexes: [List] **Optimization Recommendations**: 1. [Specific database optimization] 2. [Specific database optimization] ### ⚙️ Backend Performance **Algorithm Complexity**: - O(n²) operations found: [Count and locations] - Memory-intensive operations: [List] **Async Performance**: - Sequential operations that could be parallel: [Count] - Blocking operations: [List] **Optimization Recommendations**: 1. [Specific backend optimization] 2. [Specific backend optimization] ### 🎨 Frontend Performance **Bundle Analysis**: - Total bundle size: [XKB] - Largest dependencies: [List with sizes] - Code splitting: [Enabled/Not enabled] - Tree shaking: [Effective/Ineffective] **Rendering Performance**: - Unnecessary re-renders: [Count and components] - Large lists without virtualization: [List] - Unoptimized images: [Count] **Web Vitals**: | Metric | Current | Target | Status | |--------|---------|--------|--------| | LCP | [Xs] | < 2.5s | ✅ / ⚠️ / ❌ | | FID | [Xms] | < 100ms | ✅ / ⚠️ / ❌ | | CLS | [X] | < 0.1 | ✅ / ⚠️ / ❌ | | TTI | [Xs] | < 3.8s | ✅ / ⚠️ / ❌ | **Optimization Recommendations**: 1. [Specific frontend optimization] 2. [Specific frontend optimization] ### 🌐 Network Performance **API Performance**: - Average API response time: [Xms] - Slowest endpoints: [List with times] - API calls that could be batched: [Count] - Missing caching: [List] **Resource Loading**: - Total page size: [XMB] - Number of requests: [X] - Compression enabled: [Yes/No] - CDN usage: [Yes/No/Partial] **Optimization Recommendations**: 1. [Specific network optimization] 2. [Specific network optimization] --- ## Scalability Assessment **Current Load Capacity**: [X requests/second] **Bottlenecks for Scaling**: 1. [Bottleneck 1] 2. [Bottleneck 2] **Horizontal Scaling**: [Ready|Needs Work|Not Possible] **Vertical Scaling**: [Efficient|Acceptable|Memory/CPU intensive] **Recommendations for Scale**: 1. [Scaling recommendation 1] 2. [Scaling recommendation 2] --- ## Performance Optimization Roadmap ### Immediate (This Week) - Quick Wins - [ ] [Quick optimization 1 - estimated Xms improvement] - [ ] [Quick optimization 2 - estimated XKB reduction] ### Short-term (This Month) - High Impact - [ ] [Optimization 1 - estimated impact] - [ ] [Optimization 2 - estimated impact] ### Long-term (This Quarter) - Strategic - [ ] [Strategic improvement 1] - [ ] [Strategic improvement 2] **Expected Overall Improvement**: [X% faster, XKB smaller, etc.] --- ## Performance Testing Recommendations 1. **Load Testing**: [Specific scenarios to test] 2. **Stress Testing**: [Peak load scenarios] 3. **Profiling**: [Areas to profile with tools] 4. **Monitoring**: [Metrics to track continuously] --- ## Tools & Resources **Profiling Tools**: - Chrome DevTools Performance tab - React DevTools Profiler - Node.js --prof for CPU profiling - clinic.js for Node.js diagnostics **Monitoring Tools**: - [Recommended monitoring setup] - [Metrics to track] --- ## Review Metadata - **Reviewer**: 10x Fullstack Engineer (Performance Focus) - **Review Date**: [Date] - **Performance Issues**: Critical: X, High: X, Medium: X, Low: X - **Estimated Total Performance Gain**: [X% improvement] ``` ## Agent Invocation This operation MUST leverage the **10x-fullstack-engineer** agent with performance expertise. ## Best Practices 1. **Measure First**: Use profiling data, not assumptions 2. **Optimize Hotspots**: Focus on code that runs frequently 3. **Balance Trade-offs**: Consider readability vs performance 4. **Think Scale**: How will this perform with 10x, 100x data? 5. **User-Centric**: Optimize for perceived performance 6. **Incremental Optimization**: Make measurable improvements iteratively