#git #performance #version-control #mercurial #rebase
#git #Производительность #управление версиями #mercurial #перебазирование
Вопрос:
rebase Расширение к mercurial предоставляет функциональность, аналогичную git rebase .
Выполнение перебазирования занимает около 4 минут (~ 240 с) для 100 коммитов.
В моем воображении это должно быть чрезвычайно быстро, максимум несколько секунд, но, очевидно, я чего-то не хватает.
Почему это занимает так много времени? Сами коммиты просто чрезвычайно дороги?
Комментарии:
1. Я полагаю, вам пришлось бы создавать идентичные тестовые примеры в hg и git, чтобы можно было провести объективное сравнение. Но ИМХО с hg я согласен, что перебазирование происходит небыстро.
2. Я регулярно перебазировал свои изменения такого размера, и я сталкивался с подобными замедлениями, когда в коммитах были большие двоичные объекты. Есть ли у вас большие двоичные объекты в вашей исходной ветке / head, которые вы пытаетесь перебазировать? Вычисление sha для больших двоичных объектов может быть убийцей здесь.
3. @Arun ты имеешь в виду двоичные двоичные объекты? В репозитории, вероятно, где-то есть. В наборе коммитов, которые я перебазирую, нет двоичных двоичных объектов.
Ответ №1:
По умолчанию rebase выполняет запись в рабочую копию, но вы можете настроить его на запуск в памяти для повышения производительности и разрешить ему запускаться, если рабочая копия загрязнена. Просто добавьте следующие строки в свой .hgrc файл:
[rebase]
experimental.inmemory = True
(Чтобы получить больше настроек для перебазирования, попробуйте выполнить hg help rebase )
Комментарии:
1. Но почему запись в рабочую копию происходит еще медленнее? Казалось бы, это слишком медленно, чтобы даже быть заблокированным дисковым вводом-выводом, если только нет огромного объема ввода-вывода, о котором я не думаю, нет?
2. Интересно; Я перебазировал около 70 наборов изменений. Я пробовал оба способа. Изначально это было намного быстрее — первые 20 или около того. Затем это замедлилось до кажущегося нормальным. В целом все еще лучше.
3. Я вижу, что произошло. Это ускорилось в памяти, пока не столкнулось с конфликтом; затем вместо этого все началось сначала на диске, и он переделал ВСЕ те, через которые он проходил до конфликта.
4. Я выполнил еще один со 115 наборами изменений — никаких конфликтов — и это, должно быть, было в ~ 5 раз быстрее.