Борьба с вечными проблемами оптимизации в Python, особенно с сортировкой и управлением памятью pymalloc, часто заканчивается разочарованием. Историю знает каждый: почти все случаи нестабильной работы, о которых сообщают пользователи, сначала попадают на Stack Overflow, где неопределённые пользователи жалуются на «необъяснимые замедления». Когда автор писал текущую версию сортировки в Python, данные о времени выполнения приходили лишь от тех, кто запускал синтетический бенчмарк sortperf.py, включённый в стандартное дистрибутивное пакетное обеспечение. Реальные приложения на реальных данных представляли единицы примеров. Пользователи делились результатами вроде «быстро на 2x!», но не могли предоставить данные своей компании из-за ограничений конфиденциальности. Лишь недавно автор практически умолял участников сообщать исключительно результаты таймингов, без необходимости передачи самих данных, и это принесло единственную конструктивную реакцию.
Похожая история наблюдается при оценке стратегий разрешения коллизий в реализации dict. Исследования почти всегда ведутся на синтетических данных, и почти все стратегии кроме текущей были отброшены из-за катастрофического поведения на редких кейсах из реальной жизни. Тем не менее, доказано, что коллекции ключей, приводящие к катастрофам, существуют всегда; вопрос лишь в том, насколько вероятно, что реальные данные случайно попадут в такую ловушку. Этот подход не уникален для Python. Учёный и академик Себастиан Вильд, совместно создавший выдающуюся эвристику упорядочивания merge-ordering powersort, также столкнулся с крайне плохим откликом на свои настойчивые просьбы предоставить «реальные данные мира». В основном он привлекает искусственно сконструированные примеры с плохим поведением.
Уже на ранних этапах автор открыл тикет о поведении с квадратичным временем выполнения на главной ветке разработки. Тогда автор не знал, что виной являются изменения в сборщике мусора gc, и созданный тестовый кейс практически не создавал циклов. Тем не менее, он вызывал эвристики того времени к работе частей gc гораздо чаще, чем это было разумно. Поведение в худшем случае у сортировки довольно предсказуемо и работает по порядку O(), но контекст работы сборщика мусора гораздо грязнее. Это верно без сомнений. Конечно, предсказать среднее поведение сложно, так как «типичного приложения» вообще не существует, но такие тесты помогают уточнить границы того, что можно увидеть в реальной жизни. Это создаёт убедительный случай для возможности легко тестировать изменения в gc на этапе продакшн-релиза. Без этого шансов получить какую-либо обратную связь от реального мира сводится к почти нулю, особенно для катастрофических случаев. Приходится играть теми руками, которые нам достались.