Почему чужой код кажется быстрее
Фрагмент с форума обычно решает узкую задачу: например, быстро сортирует данные или обрабатывает строку. Его автор мог заменить простой, но затратный шаг более подходящим алгоритмом, сократить копирование данных или использовать особенности конкретной библиотеки. Такой пример привлекателен тем, что его можно быстро проверить, не переписывая приложение целиком.
Но «оптимизированный» не означает «быстрее всегда». Скорость зависит от размера и формы входных данных, языка, компилятора и среды выполнения. При небольшом наборе данных сложный алгоритм может проиграть простому из-за дополнительных расходов; а при другом формате данных фрагмент может вовсе работать неверно.
Что происходит после вставки
Скомпилироваться — значит пройти проверку синтаксиса и типов, а не доказать, что программа делает нужное. Поэтому фрагмент приходится подгонять под приложение: согласовывать типы и версии библиотек, учитывать обработку ошибок, граничные случаи и то, как остальной код обращается с данными. Иногда пример рассчитывает на условия, которые в исходном проекте не выполняются.
Проверка скорости тоже требует сравнения в одинаковых условиях. Если измерить только сам фрагмент, можно не заметить, что он ускорил один шаг, но добавил работу до или после него. И даже удачная локальная оптимизация может сделать код сложнее для сопровождения.
Быстрый пример — не готовое решение
Разумный путь — сначала понять, какое именно узкое место устраняет найденный код, затем проверить его на данных приложения и сравнить результат с прежней версией. Тогда заимствование становится не копированием на веру, а проверяемым изменением. Иначе приложение может получить эффектный фрагмент, который работает в демонстрации, но не ускоряет реальную задачу.
