Производительность

C и C++ оптимизируют кэш, ветвления и векторизацию: работа уже скомпилирована, узкое место — доступ к памяти. В Python на этом уровне бороться не с чем, пока данные лежат объектами: любая операция дороже кэш-промаха на порядки. Поэтому первый рычаг здесь — не раскладка, а уход от объектов: numpy и есть способ вернуться в мир, где раскладка снова имеет значение.

Показательно, что после перехода на numpy советы из C начинают работать буквально: непрерывность, тип элемента, размер батча, векторизация — та же оптимизация, что и в C, потому что данные наконец лежат так же.

Java и JavaScript с их JIT решают ровно ту задачу, которую CPython начал решать в 3.11: специализировать динамический код по факту исполнения. V8 пришёл к инлайн-кешам в 2008-м, CPython — в 2022-м. Разрыв объясняет и отставание в скорости, и то, почему оно сокращается.

Прогони фрагменты, сверяясь с предсказанием. Затем:

import dis

class P:
    def __init__(self): self.x = 1

p = P()
def f(o): return o.x

dis.dis(f, adaptive=True)
for _ in range(200): f(p)
dis.dis(f, adaptive=True)
# Что изменилось в инструкциях после прогрева?

import tracemalloc
tracemalloc.start()
data = [{"i": i} for i in range(100_000)]
print(tracemalloc.get_traced_memory())
# Сколько памяти стоит горячий путь? Это второй по важности вопрос после «где время».

import timeit
print(timeit.timeit("sum(range(1000))", number=10_000))
print(timeit.timeit("total=0\nfor i in range(1000): total+=i", number=10_000))
# Во сколько раз? Почему встроенная функция выигрывает?

И одна проверка из терминала — сколько времени старта уходит на импорты (урок 17):

python -X importtime -c "import myapp" 2>&1 | sort -k2 -nr | head

Последний вопрос выводит на общий принцип: любая работа, целиком выполненная внутри одной встроенной функции, не выходит в интерпретатор на каждой итерации — и потому дешевле цикла, делающего то же самое.

Lib/cProfile.py и Lib/pstats.py. Стоит один раз прочитать pstats, чтобы перестать смотреть на профиль как на стену текста: там всего несколько методов сортировки и фильтрации, и print_callers с print_callees отвечают на вопрос «кто это вызывает» лучше, чем чтение кода.

Lib/dis.py. Параметр adaptive=True показывает специализированные инструкции — единственный способ увидеть, применилась ли оптимизация из урока 04 к твоему коду. Полезно на горячем цикле: если инструкции остались общими, значит специализация не удалась, и стоит понять почему.

Lib/timeit.py. Заметь, что он по умолчанию отключает сборщик мусора и берёт минимум из прогонов, а не среднее. Оба решения объяснены в исходнике и объясняют, почему timeit даёт цифры лучше самодельного замера через time.perf_counter.

Из L1 ты знаешь порядок рычагов. Здесь — из чего складывается стоимость.

Ориентиры на 3.11, порядок величин, а не точные числа:

Главный вывод из таблицы: создание объекта дороже любой отдельной операции над уже существующими. Поэтому первый вопрос при оптимизации горячего цикла — не «какие операции сделать быстрее», а «какие объекты не создавать»: промежуточные списки, временные строки, обёртки.

Про специализацию. Инструкция специализируется после нескольких исполнений и обесценивается при изменении класса. Посмотреть можно так:

import dis
def f(o): return o.x
class A:
    def __init__(self): self.x = 1
a = A()
for _ in range(100): f(a)
dis.dis(f, adaptive=True)
# → LOAD_ATTR_INSTANCE_VALUE вместо общего LOAD_ATTR

Если после прогрева инструкция осталась общей, специализация не удалась — типичные причины перечислены в Python/specialize.c: слишком много разных типов в одном месте, динамические изменения класса, необычные дескрипторы. Это и есть механизм следствия 4.

Тег v3.11.15.

• Python/specialize.c — как принимается решение специализировать инструкцию и по каким причинам не получается. Список причин отказа сам по себе полезен как чеклист.
• Python/ceval.c — цикл интерпретатора: видно, что специализированные инструкции это отдельные ветви.
• Objects/frameobject.c — фреймы, ставшие в 3.11 дешевле; отсюда падение стоимости вызова.
• PEP 659 — специализирующий адаптивный интерпретатор; PEP 744 — JIT, следующий шаг.

• 🟥py-spy — читать README целиком. Выборочный профилировщик, работающий на живом процессе без перезапуска; практически незаменим на проде.
• 🟧PEP 659 — выборочно: мотивация и раздел про инлайн-кеши. Объясняет, почему старые советы перестали работать.
• 🟦Документация profile и pstats — хватит разбора выше; полезен список ключей сортировки.