Профилирование Python-кода с py-spy: находим узкие места на примере расчёта расстояний между аэропортами

Когда код летает медленнее самолёта

Представьте: у вас есть датасет из 3.5 миллионов записей о полётах между аэропортами. Нужно рассчитать расстояние между каждой парой точек по формуле Haversine. В теории - пара строк кода. На практике - скрипт выполняется 45 минут и съедает всю память.

Знакомая ситуация? Каждый data scientist сталкивался с этим. Вы пишете чистый, понятный код на Pandas, запускаете его на реальных данных - и получаете производительность хуже, чем у Excel на Pentium 4.

Почему стандартные профилировщики не работают

Вы пробовали cProfile? Line profiler? Они показывают красивые отчёты, но есть проблема. Эти инструменты добавляют оверхед в 10-100 раз. На больших данных они сами становятся узким местом.

Py-spy работает иначе. Это sampling profiler, который читает память процесса извне. Нулевой оверхед. Можно профилировать продакшен без остановки сервиса. Магия? Нет, просто грамотная инженерия.

Наш подопытный кролик: код, который нужно оптимизировать

Допустим, у нас есть CSV файл с 3.5 млн строк. Каждая строка - информация о полёте: аэропорт вылета, аэропорт прилёта, их координаты. Нужно посчитать расстояние для каждой записи.

Типичный код новичка выглядит так:

import pandas as pd
import numpy as np
from math import radians, sin, cos, sqrt, asin

def haversine_slow(row):
    """Наивная реализация Haversine через apply"""
    lat1, lon1 = radians(row['origin_lat']), radians(row['origin_lon'])
    lat2, lon2 = radians(row['dest_lat']), radians(row['dest_lon'])
    
    dlat = lat2 - lat1
    dlon = lon2 - lon1
    
    a = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2
    c = 2 * asin(sqrt(a))
    
    return 6371 * c  # радиус Земли в км

def process_data_naive():
    df = pd.read_csv('flights_3.5m.csv')
    
    # Самый медленный способ
    df['distance'] = df.apply(haversine_slow, axis=1)
    
    return df

if __name__ == '__main__':
    result = process_data_naive()
    print(f"Обработано {len(result)} строк")

Этот код работает. Правильно считает расстояния. И ужасно медленный. Почему? Давайте разбираться с py-spy.

Установка и первый запуск: видим проблему в лицо

1 Установка py-spy

На Linux/Mac:

pip install py-spy

На Windows нужно установить Rust и собрать из исходников, или использовать WSL2 (рекомендую).

2 Запуск профилирования

Сохраняем наш медленный код как slow_distance.py и запускаем:

# Запускаем профилирование с записью в файл
py-spy record -o profile.svg -- python slow_distance.py

# Или в реальном времени
py-spy top -- python slow_distance.py

Первая команда создаст SVG файл с flame graph. Вторая покажет live-профилирование, похожее на top в Linux.

3 Анализируем результаты

Flame graph выглядит как разноцветные полоски. Ширина полоски - сколько времени функция занимала. Высота - стек вызовов.

Что мы увидим в нашем случае:

• 90% времени в pandas.core.apply
• Постоянные вызовы haversine_slow для каждой строки
• Много времени в Python overhead (вызовы функций, boxing/unboxing)

Проблема ясна: apply - это просто цикл по строкам на Python уровне. Для каждой строки создаётся Series объект, вызывается функция, результат упаковывается обратно. Кошмар для производительности.

Оптимизация шаг за шагом: от медленного к быстрому

Версия 1: Векторизация с NumPy

Первое правило оптимизации Pandas: избегайте apply. Второе правило: смотрите первое правило.

def haversine_vectorized(df):
    """Векторизованная версия"""
    # Конвертируем сразу все значения
    lat1 = np.radians(df['origin_lat'].values)
    lon1 = np.radians(df['origin_lon'].values)
    lat2 = np.radians(df['dest_lat'].values)
    lon2 = np.radians(df['dest_lon'].values)
    
    dlat = lat2 - lat1
    dlon = lon2 - lon1
    
    # Векторизованные операции
    a = np.sin(dlat/2)**2 + np.cos(lat1) * np.cos(lat2) * np.sin(dlon/2)**2
    c = 2 * np.arcsin(np.sqrt(a))
    
    return 6371 * c

def process_data_vectorized():
    df = pd.read_csv('flights_3.5m.csv')
    df['distance'] = haversine_vectorized(df)
    return df

Запускаем py-spy снова. Результат: ускорение в 50-100 раз. Вместо отдельных вызовов для каждой строки - операции над целыми массивами NumPy.

Версия 2: Оптимизация памяти

Py-spy показывает новую проблему: много времени тратится на чтение CSV и создание промежуточных массивов. Решение:

def process_data_optimized():
    # Используем правильные типы сразу
    dtypes = {
        'origin_lat': 'float32',
        'origin_lon': 'float32', 
        'dest_lat': 'float32',
        'dest_lon': 'float32'
    }
    
    # Читаем только нужные колонки
    cols = ['origin_lat', 'origin_lon', 'dest_lat', 'dest_lon']
    df = pd.read_csv('flights_3.5m.csv', usecols=cols, dtype=dtypes)
    
    # Оптимизированная версия с меньшим потреблением памяти
    lat1 = np.radians(df['origin_lat'].to_numpy())
    lat2 = np.radians(df['dest_lat'].to_numpy())
    lon1 = np.radians(df['origin_lon'].to_numpy())
    lon2 = np.radians(df['dest_lon'].to_numpy())
    
    # Используем fused multiply-add для точности
    dlat = lat2 - lat1
    dlon = lon2 - lon1
    
    sin_dlat = np.sin(dlat * 0.5)
    sin_dlon = np.sin(dlon * 0.5)
    
    a = sin_dlat * sin_dlat + np.cos(lat1) * np.cos(lat2) * sin_dlon * sin_dlon
    
    # Более стабильный sqrt
    mask = a > 1.0
    a[mask] = 1.0
    
    c = 2 * np.arcsin(np.sqrt(a))
    
    df['distance'] = 6371.0 * c
    return df

Ещё одно профилирование. Видим, что потребление памяти упало в 2 раза, скорость ещё выросла на 20%.

Версия 3: Когда нужно ещё быстрее

Иногда даже векторизации недостаточно. Py-spy может показать, что bottleneck в математических функциях. Тогда переходим на Numba или Cython.

Но перед этим - проверьте, действительно ли это нужно. В 95% случаев векторизации хватает.

Продвинутые техники профилирования с py-spy

Профилирование в продакшене

Py-spy умеет подключаться к уже работающим процессам:

# Находим PID процесса
pgrep -f "python.*myapp"

# Подключаемся к процессу
py-spy record -p 12345 -o prod_profile.svg

# Или дамп стека всех Python процессов
py-spy dump -p 12345

Это бесценно для отладки проблем в production. Увидели, что сервис начал тормозить? Подключились, сняли профиль, нашли проблему.

Профилирование многопоточных приложений

# Профилирование с разделением по потокам
py-spy record --subprocesses -o thread_profile.svg -- python my_threaded_app.py

# Только определённый поток
py-spy record -p PID --gil -o gil_wait.svg

Флаг --subprocesses показывает все потоки. --gil помогает найти contention на Global Interpreter Lock.

Сравнение профилей до и после оптимизации

Сохраняйте SVG файлы с разными версиями кода. Открывайте их рядом в браузере. Видите, как толстые полоски (медленные функции) становятся тоньше или исчезают.

Это лучшая мотивация для оптимизации - визуальное подтверждение, что ваш код стал лучше.

Типичные ошибки, которые находит py-spy

Py-spy vs другие инструменты: когда что использовать

Py-spy - не серебряная пуля. Для разных задач нужны разные инструменты:

• Py-spy: поиск узких мест в целом, production profiling, быстрая диагностика
• cProfile: точное измерение времени вызовов, анализ вызовов функций
• Line profiler: понимание, какая именно строка кода медленная
• Memory profiler: утечки памяти, потребление памяти по строкам
• Scalene: CPU, GPU и память вместе (новый инструмент, набирающий популярность)

Мой стек: начинаю с py-spy для общего взгляда, затем line profiler для конкретных функций, memory profiler если есть подозрения на утечки.

Реальные цифры: насколько мы ускорили расчёт расстояний

Давайте подведём итоги на нашем примере с аэропортами:

• Наивная версия (apply): 45 минут, 8 ГБ памяти
• Векторизованная версия: 45 секунд, 4 ГБ памяти
• Оптимизированная версия: 35 секунд, 2 ГБ памяти

Ускорение в 77 раз. И это без переписывания на C++ или использования GPU. Просто грамотная работа с данными.

Что делать, если py-spy не показывает проблему

Бывает так: py-spy показывает, что всё хорошо, но код всё равно медленный. Возможные причины:

1. I/O bound задача: код ждёт диска или сети. Py-spy показывает CPU время, а вы ждёте 90% времени.
2. Проблема вне Python: медленная база данных, внешний API, системные вызовы.
3. Слишком короткий запуск: py-spy не успел набрать статистику.

Решение: используйте --native флаг для профилирования системных вызовов, или комбинируйте с другими инструментами.

Интеграция в CI/CD: не допускаем регрессии производительности

Py-spy можно использовать в пайплайнах:

# Скрипт для проверки производительности
#!/bin/bash

# Запускаем тест
py-spy record -o profile.svg -- python performance_test.py

# Парсим результаты (пример)
if grep -q "apply\|iterrows" profile.svg; then
    echo "WARNING: Found slow patterns in code"
    exit 1
fi

Или более продвинутый вариант: сохраняйте базовый профиль, сравнивайте с новым, падайте если производительность упала больше чем на X%.

Это особенно важно для библиотек и фреймворков, где пользователи ждут стабильной производительности.

Совет, который редко дают

Py-spy показывает где тратится время, но не почему. После того как нашли узкое место - включайте мозг.

Пример из практики: py-spy показал, что много времени в функции сортировки. Оказалось, что данные уже были отсортированы, но код каждый раз проверял это, вызывая дорогую операцию. Убрали проверку - ускорили в 3 раза.

Инструменты дают данные. Инженерное мышление даёт решения.

Начните использовать py-spy сегодня. Не ждите, пока код станет невыносимо медленным. Профилируйте регулярно, как чистку зубов. Через месяц у вас выработается интуиция - вы будете чувствовать, где будет узкое место, ещё до запуска профилировщика.

И помните: быстрый код - это не только про экономию времени. Это про возможность работать с большими данными, про снижение затрат на инфраструктуру, про возможность делать больше итераций в исследовании. В data science скорость кода напрямую влияет на качество исследований.