Я участвую в открытом инструменте командной строки для мобильной автоматизации fastlane , написанном на ruby.У нас проблема в том, что fastlane нужно довольно долго запускаться, прежде чем он начнет работать.В зависимости от ОС (у нас MacOS, Ubuntu и Windows) и машины это может занять от 0,5 до 30 секунд.
(Примечание: проблема гораздо менее заметна, когда вы используете bundle exec fastlane для запуска командыЯ работал над версией без этого, так как изменения были легче идентифицировать и отслеживать с более длительным временем выполнения. Все улучшения также сводятся к уже более быстрой bundle exec версии, конечно)
Снекоторые профилирование с rbspy Я знаю, что большую часть времени тратится на загрузку файлов.Поэтому имеет смысл, когда командам, которые на самом деле не выполняют какой-либо существенный код, требуется такое же время для запуска, как и всем остальному.
Я использовал взломанную версию backload для вывода всех require и require_relative действий из приложения: обычный запуск может создать> 1100 из них.Таким образом, каждый запуск загружает 1100 файлов (из самого fastlane или драгоценных камней, которые мы используем).
В настоящее время в fastlane есть несколько файлов, в которые загружаются все «вспомогательные функции» - например, fastlane_core.rb, которые require_relative s все файлы в fastlane_core - независимо от того, нужен код на самом деле или нет.
Так что моя идея была очевидна: избавиться от преждевременной загрузки и просто загрузить, когда код действительно необходим (что уже происходит, но не было активным, потому что материал загружался раньше).
Вы можете посмотреть на запрос на выполнение работ в процессе выполнения с моими изменениями здесь .
Первые результаты нашего CI были очень многообещающими (мы запустили небольшой тестовый скрипт в рамках нашего тестового прогона):
До каких-либо изменений:
macOS: 1.6, 1.5, 1.6
Ubuntu: 2.0, 2.1, 2.0
Windows: 2.5, 2.4, 2.4
После изменений:
macOS: 1.0, 0.9, 0.8
Ubuntu: 1.0, 0.9, 0.9
Windows: 2.1, 2.0, 2.1
Так что я могу улучшить время запуска на всех платформах в этих средах.
НО это не воспроизводится на моей локальной машине.
Здесь, на медленном Windows Ultrabook несколько лет назад, та же самая команда обычно занимает ~ 30 секунд.Но после изменений теперь это занимает 50 секунд.Имеет ли это какой-то смысл?
Я сравнил список backload всех требований до и после изменения:
Это представление «diff» WinMerge, которое показывает перемещенные блоки коричневым цветом и удаленные блоки желтым.Таким образом, после изменений материал в основном загружается позже (более коричневый внизу), а некоторые вещи вообще не загружаются (желтый).В целом он работает меньше (~ 800 против ~ 1100). Почему это может быть медленнее на этой машине?