Есть ли опыт профилирования памяти и производительности в Python
Что проверяют
Умеете ли вы искать узкое место измерением, а не догадкой, и знаете ли, какой инструмент брать под какую задачу. Следом просят рассказать конкретный случай: что тормозило, чем нашли, что изменили и как проверили эффект.
Как отвечать
Ответ строится на вашей реальной истории, но инструменты стоит назвать точно:
cProfileиpstats: встроенный детерминированный профилировщик.python -m cProfile -o out.prof app.py, сортировка поcumtime, визуализация черезsnakeviz. Даёт заметный оверхед и искажает картину для мелких частых функций;py-spy: сэмплирующий профилировщик, подключается к работающему процессу по PID без перезапуска (py-spy top,py-spy recordдля flame graph). Годится для прода;line_profiler: построчное время внутри конкретной функции черезkernprof, когда горячая функция уже найдена;tracemalloc: встроенный модуль, снимки памяти иcompare_toмежду ними показывают, какие строки кода накопили объекты. Хорош для поиска утечки;memrayилиscalene: подробный профиль аллокаций, включая нативные расширения вродеnumpy.
Каркас истории: симптом с цифрами (эндпоинт отвечает 3 секунды, воркер растёт по памяти до OOM), как воспроизвели на реалистичных данных, что показал профиль, что поменяли, как замерили после. Типичные находки: N+1 запросы к базе через ORM, лишняя сериализация, список там, где хватило бы генератора, кэш без ограничения размера. Цифры должны быть вашими. Если опыта с продом не было, честно скажите, что профилировали локально или на учебной задаче, и покажите, как бы действовали.
Где спотыкаются
Называют круглые проценты «ускорил на 50%», но не могут сказать, как мерили и на каких данных. Это первое, что уточнит интервьюер.
Профилируют на игрушечном объёме. На ста строках узким местом выглядит одно, на миллионе совсем другое.
Смотрят на RSS процесса и делают вывод об утечке. CPython не всегда возвращает освобождённую память операционной системе, поэтому рост RSS ещё не значит, что объекты остались живы: проверяйте через tracemalloc.