7 промтов для оптимизации производительности кода: находим узкие места за секунды

7 промтов для оптимизации производительности кода: находим узкие места за секунды

Вы когда-нибудь тратили часы на поиск причины, почему приложение тормозит, а потом оказывалось, что дело в одном неоптимальном цикле или неправильно настроенном индексе базы данных? Знакомая история. С появлением больших языковых моделей (LLM) процесс профилирования и оптимизации кода перестал быть исключительно ручной работой. Теперь вы можете скормить промту дамп стека или фрагмент кода, и получить готовый план действий.

В этой статье — 7 конкретных промтов, которые я использую в своей ежедневной работе. Они помогут вам быстрее находить узкие места, рефакторить legacy-код и писать эффективные запросы. Поехали.

Почему промты — это новый must-have для performance-инженера

Традиционный подход к оптимизации выглядит так: запустил профайлер, получил флейм-граф, начал гуглить каждый странный вызов. Это занимает от 30 минут до нескольких часов. С промтами этот процесс сжимается до 2–3 минут. Вы просто копируете код или вывод профайлера и получаете готовый ответ с конкретными строками, которые нужно исправить.

По данным опроса Stack Overflow за 2025 год, 62% разработчиков хотя бы раз использовали LLM для отладки и оптимизации кода. И это число растёт. Но ключевой навык — не просто задать вопрос, а задать правильный промт с контекстом.

Промт 1: Анализ узких мест по выводу профайлера

Когда использовать: Вы запустили cProfile, Xdebug или Chrome DevTools и получили таблицу с временем выполнения. Нужно быстро понять, какие функции — кандидаты на оптимизацию.

Промт:

Ты — senior performance engineer. Проанализируй вывод профайлера ниже. Определи ТОП-5 функций, которые занимают больше всего времени. Для каждой укажи:
- имя функции и файл
- общее время выполнения (cumulative time)
- количество вызовов
- рекомендацию по оптимизации (кэширование, замена алгоритма, асинхронность)
- пример кода с улучшением

Вывод профайлера:
[вставьте сюда вывод]

Пример использования:
Я скопировал вывод cProfile для парсера логов на Python. Промт сразу указал, что функция re.split() вызывается 45 000 раз и занимает 68% времени. Рекомендация: заменить регулярное выражение на str.split() с предварительной очисткой. После замены скорость выросла в 3 раза.

Промт 2: Оптимизация SQL-запросов с помощью EXPLAIN ANALYZE

Когда использовать: Медленный запрос в production, нужно понять, почему не используется индекс или где полный перебор таблиц.

Промт:

Ты — DBA с 10-летним стажем. Проанализируй план выполнения запроса (EXPLAIN ANALYZE). Для каждого узла укажи:
- тип сканирования (Seq Scan, Index Scan, Bitmap Heap Scan)
- стоимость (cost) и реальное время (actual time)
- количество строк (rows vs actual rows)
- если есть Seq Scan на большой таблице — предложи конкретные индексы
- напиши оптимизированную версию запроса

EXPLAIN ANALYZE:
[вставьте сюда вывод]

Пример использования:
Запрос поиска заказов за последний месяц выполнялся 12 секунд. Промт обнаружил, что PostgreSQL делает Seq Scan по таблице на 5 миллионов строк, хотя есть индекс по дате. Причина — использование DATE(order_date) в WHERE, что делает индекс бесполезным. Рекомендация: заменить на order_date >= CURRENT_DATE - INTERVAL '1 month'. Время выполнения упало до 80 мс.

Промт 3: Рефакторинг legacy-кода с акцентом на производительность

Когда использовать: Вы работаете с кодом, которому 5–10 лет, и нужно улучшить его, не ломая бизнес-логику.

Промт:

Ты — рефакторинг-эксперт. Ниже приведён фрагмент legacy-кода. Твои задачи:
1. Найти топ-3 проблемы производительности (с указанием конкретных строк)
2. Предложить оптимизированную версию с комментариями изменений
3. Убедиться, что поведение не меняется (напиши unit-тест для проверки)
4. Оценить ожидаемый прирост производительности (в процентах)

Код:
```[язык]
[вставьте код]

**Пример использования:**
Код на PHP из легаси-проекта обрабатывал CSV-файлы построчно с помощью `fgetcsv()` в цикле. Промт показал, что файл читается 3 раза для разных целей. Рекомендация: читать один раз и сохранять в массив. Также указал на неиспользуемый `array_merge()` внутри цикла, который создавал копию массива на каждой итерации. После рефакторинга время обработки файла на 500 000 строк сократилось с 45 секунд до 4 секунд.

## Промт 4: Анализ использования памяти и поиск утечек

**Когда использовать:** Приложение падает с OutOfMemoryError, или память растёт бесконтрольно.

**Промт:**

Ты — специалист по управлению памятью. Проанализируй дамп кучи (heap dump) или вывод memory profiler. Найди:
- объекты, которые занимают больше всего памяти (ТОП-5 классов)
- кто держит ссылки на эти объекты (GC root)
- есть ли признаки утечки (количество объектов растёт со временем)
- предложи 3 способа исправить ситуацию

Данные:
[вставьте вывод heap dump или описание симптомов]

**Пример использования:**
Java-приложение падало раз в 2 часа. Разработчики не могли найти причину. Я скормил промту вывод `jmap -histo:live`. Промт указал на класс `SessionContext` — 500 000 экземпляров. Проблема: сессии не закрывались после таймаута. Рекомендация: добавить `session.invalidate()` в фильтр. После фикса память стабилизировалась на уровне 200 МБ вместо 2 ГБ.

## Промт 5: Оптимизация сетевых запросов и API

**Когда использовать:** Мобильное приложение или веб-сервис тормозит из-за множества HTTP-запросов.

**Промт:**

Ты — performance architect для распределённых систем. Проанализируй трассировку сетевых запросов (Waterfall из DevTools или Jaeger). Укажи:
- общее количество запросов и их общую длительность
- какие запросы можно объединить (batching)
- какие данные можно кэшировать на клиенте
- есть ли последовательные запросы, которые можно сделать параллельными
- предложи конкретные изменения в коде

Трассировка:
[вставьте описание или скриншот текстом]

**Пример использования:**
Веб-приложение загружало дашборд 8 секунд. Промт проанализировал Waterfall и обнаружил, что 15 запросов к `/api/analytics` выполняются последовательно, хотя они независимы. Рекомендация: заменить на `Promise.all()` с лимитом конкурентности 5. Время загрузки сократилось до 1.8 секунд.

## Промт 6: Оптимизация Python/Django кода (с учётом N+1 и жадной загрузки)

**Когда использовать:** Django-приложение медленно рендерит страницы из-за ORM-запросов.

**Промт:**

Ты — Django performance expert. Проанализируй код ниже и:
- найди проблему N+1 запросов (укажи конкретные строки)
- предложи использовать select_related или prefetch_related
- проверь, есть ли неэффективные циклы с запросами внутри
- напиши оптимизированную версию с использованием annotate и агрегации
- добавь индексы в модели, если нужно

Код:
[вставьте views.py или models.py]

**Пример использования:**
Страница списка товаров загружалась 6 секунд. Промт нашёл, что в шаблоне для каждого товара выполняется отдельный запрос к категории — классический N+1. Рекомендация: добавить `prefetch_related('category__parent')`. После оптимизации страница стала загружаться за 200 мс.

## Промт 7: Оптимизация CI/CD пайплайна

**Когда использовать:** Сборка проекта занимает 20–30 минут, разработчики ждут.

**Промт:**

Ты — DevOps performance engineer. Проанализируй лог CI/CD пайплайна и:
- найди самые долгие шаги (с указанием времени)
- определи, какие шаги можно распараллелить
- предложи кэширование зависимостей (с примерами конфигурации для GitHub Actions/GitLab CI)
- оцени, насколько можно сократить общее время сборки

Лог:
[вставьте лог сборки]
```

Пример использования:
CI пайплайн занимал 25 минут. Промт обнаружил, что npm install выполняется каждый раз без кэша и занимает 8 минут. Рекомендация: добавить кэширование node_modules с хешом package-lock.json. Также предложил распараллелить линтинг и тесты. Итог: время сборки сократилось до 6 минут.

Таблица: когда какой промт использовать

Как адаптировать промты под свой стек

Универсальных промтов не существует — их нужно адаптировать. Вот ключевые правила:

1. Указывайте язык и версию. Python 3.8 и Python 3.12 — разные языки в плане оптимизаций. Пример: "Платформа: Python 3.12 на Linux x86_64".
2. Давайте контекст. Если код работает с большими данными, укажите это. LLM тогда предложит batch-обработку, а не однопоточный парсинг.
3. Просите конкретные строки. Вместо "найди проблемы" скажите "найди строки с сложностью O(n²) и предложи замену на O(n log n)".
4. Добавляйте ограничения. Например: "Решение не должно увеличивать использование памяти более чем на 10%" или "Запрос должен выполняться менее 100 мс".

Частые ошибки при использовании промтов для оптимизации

1. Слишком общий запрос. Промт "оптимизируй этот код" даст поверхностные советы. Нужно указывать метрики: "ускорь выполнение функции, которая вызывается 10^6 раз".
2. Игнорирование контекста. LLM не знает, что ваш код работает на Raspberry Pi с 512 МБ RAM. Если не указать — получите советы, которые не влезут в память.
3. Слепое копирование. Всегда проверяйте предложенные изменения. Однажды промт предложил удалить try-except ради скорости, но это сломало обработку ошибок.

Заключение

Промты — это не замена профайлеру, а умный ассистент, который экономит часы ручного анализа. Они особенно полезны, когда нужно быстро оценить, есть ли проблема, или когда вы работаете с незнакомым кодом. Используйте промты из этой подборки как стартовую точку, но не забывайте адаптировать их под свой стек и контекст.

Оптимизация производительности — это итеративный процесс. Сначала промт находит узкое место, вы фиксите, снова запускаете профайлер — и так до тех пор, пока не достигнете нужных метрик. И да, не верьте промту на слово — всегда проверяйте результат бенчмарком.

Эта статья подготовлена при поддержке ASI Biont. Если вы хотите глубже изучить промпт-инжиниринг и научиться писать эффективные запросы для AI-моделей, обратите внимание на наши материалы по этой теме.