laravel-audit-performance

Laravel Performance Audit

Audit how the application spends time, memory, queries, and I/O — and report only optimizations that are semantically verified and worth acting on.

List applicable rules first:

php artisan auditor:rules --domain=performance --applicable

Ecosystem rules (AUD-LW-003, AUD-FIL-003, AUD-IN-003) appear only when those packages are installed.

The methodology

Work every candidate through this pipeline. A pattern that stops at any stage is not a finding.

Signal        A suspicious shape (query in a loop, get()->count(), unbounded all())
  ↓
Context       Who calls this? What route/job/command? What data volume? What else uses the result?
  ↓
Behavior      What does the code actually do — accessors, casts, custom collections, callbacks?
  ↓
Verification  Is the proposed replacement semantically equivalent FOR THIS USAGE?
  ↓
Impact        Which resource does it save (queries, rows transferred, memory, CPU, I/O)? Is it meaningful?
  ↓
Finding       Evidence-backed report with mechanism-based impact and justified severity

A suspicious pattern is not automatically a performance bug.

Worked example — when it IS a finding

$total = User::where('active', true)->get()->count();

The collection is materialized only to be collapsed into one number. Every matching row is transferred and hydrated to produce what User::where('active', true)->count() returns as a single value. Verified: $total is a scalar; no other code uses the collection. Report via AUD-PER-008.

Counter-example — same shape, NOT a finding

$users = User::where('active', true)->get();

$count = $users->count();

return view('users.index', compact('users', 'count'));

Do not recommend ->count() here. The collection is rendered by the view; replacing the aggregate would issue a second query or force a refactor. Deriving the count from already-loaded data is the cheapest correct option. This rule applies to every "obvious" optimization in this skill: check what else consumes the value first.