# PROBLEM: N+1 - each iteration queries profile
def user_list(request):
 users = User.objects.all()
 return render(request, 'users.html', {'users': users})

# Template:
# {% for user in users %}
# {{ user.profile.bio }} ← triggers query per user
# {% endfor %}

# SOLUTION: Prefetch in view
def user_list(request):
 users = User.objects.select_related('profile')
 return render(request, 'users.html', {'users': users})

# PROBLEM: SerializerMethodField queries per object
class UserSerializer(serializers.ModelSerializer):
 order_count = serializers.SerializerMethodField()

 def get_order_count(self, obj):
 return obj.orders.count() # ← query per user

# SOLUTION: Annotate in viewset, access in serializer
class UserViewSet(viewsets.ModelViewSet):
 def get_queryset(self):
 return User.objects.annotate(order_count=Count('orders'))

class UserSerializer(serializers.ModelSerializer):
 order_count = serializers.IntegerField(read_only=True)

# PROBLEM: Property triggers query when accessed
class User(models.Model):
 @property
 def recent_orders(self):
 return self.orders.filter(created__gte=last_week)[:5]

# Used in template loop = N+1

# SOLUTION: Use Prefetch with custom queryset, or annotate

# PROBLEM: No pagination - loads all rows
class UserListView(ListView):
 model = User
 template_name = 'users.html'

# SOLUTION: Add pagination
class UserListView(ListView):
 model = User
 template_name = 'users.html'
 paginate_by = 25

# PROBLEM: Loads all objects into memory at once
for user in User.objects.all():
 process(user)

# SOLUTION: Stream with iterator()
for user in User.objects.iterator(chunk_size=1000):
 process(user)

# PROBLEM: Forces full evaluation into memory
all_users = list(User.objects.all())

# SOLUTION: Keep as queryset, slice if needed
users = User.objects.all()[:100]

# PROBLEM: Filtering on unindexed field
# User.objects.filter(email=email) # full scan if no index

class User(models.Model):
 email = models.EmailField() # ← no db_index

# SOLUTION: Add index
class User(models.Model):
 email = models.EmailField(db_index=True)

# PROBLEM: Sorting requires full scan without index
Order.objects.order_by('-created')

# SOLUTION: Index the sort field
class Order(models.Model):
 created = models.DateTimeField(db_index=True)

class Order(models.Model):
 user = models.ForeignKey(User)
 status = models.CharField(max_length=20)
 created = models.DateTimeField()

 class Meta:
 indexes = [
 models.Index(fields=['user', 'status']), # for filter(user=x, status=y)
 models.Index(fields=['status', '-created']), # for filter(status=x).order_by('-created')
 ]

# PROBLEM: N inserts, N round trips
for item in items:
 Model.objects.create(name=item['name'])

# SOLUTION: Single bulk insert
Model.objects.bulk_create([
 Model(name=item['name']) for item in items
])

# PROBLEM: N updates
for obj in queryset:
 obj.status = 'done'
 obj.save()

# SOLUTION A: Single UPDATE statement (same value for all)
queryset.update(status='done')

# SOLUTION B: bulk_update (different values)
for obj in objects:
 obj.status = compute_status(obj)
Model.objects.bulk_update(objects, ['status'], batch_size=500)

# PROBLEM: N deletes
for obj in queryset:
 obj.delete()

# SOLUTION: Single DELETE
queryset.delete()

# Slightly suboptimal
if queryset.count() > 0:
 do_thing()

# Marginally better
if queryset.exists():
 do_thing()

# Fetches all rows to count
if len(queryset) > 0: # bad if queryset not yet evaluated

# Single COUNT query
if queryset.count() > 0:

# N queries, but if N is small ( **Only flag** if loop is large or this is in a very hot path.

## Output Format

def get_queryset(self):
 return User.objects.filter(active=True) # no select_related

def get_queryset(self):
 return User.objects.filter(active=True).select_related('profile')

If no issues found: "No performance issues identified after reviewing [files] and validating [what you checked]."

**Before submitting, sanity check each finding:**
- Does the severity match the actual impact? ("Minor inefficiency" ≠ CRITICAL)
- Is this a real performance issue or just a style preference?
- Would fixing this measurably improve performance?

If the answer to any is "no" - remove the finding.

---

## What NOT to Report

- Test files
- Admin-only views
- Management commands
- Migration files
- One-time scripts
- Code behind disabled feature flags
- Tables with Querysets are lazy. Assigning to a variable doesn't execute anything.

 **Single query patterns are not N+1:**

 N+1 requires a loop that triggers additional queries. A single `list()` call is fine.

 **Missing select_related on single object fetch is not N+1:**

 N+1 requires a loop. A single object doing 2 queries instead of 1 can be reported as LOW if relevant, but never as CRITICAL/HIGH.

 **Style preferences are not performance issues:**
If your only suggestion is "combine these two lines" or "rename this variable" - that's style, not performance. Don't report it.