TortoiseHg медленный - PullRequest
       26

TortoiseHg медленный

20 голосов
/ 25 октября 2011

В основном то, что написано на банке: TortoiseHg работает медленно.

Моя команда недавно переехала из Subversion в Mercurial. (Частично, чтобы воспользоваться преимуществами Kiln для проверки кода) Одна из вещей, которые мы заметили, заключается в том, что взаимодействие с Mercurial через TortoiseHg мучительно медленное. Некоторые характеристики:

  • Open TortoiseHg Workbench: 8 минут 13 секунд
  • Время ответа при нажатии на ревизию: 2,8 секунды
  • Время «Обновить текущий репозиторий»: 6,4 секунды
  • Время для проверки входящих изменений: 12,8 секунд

Все это действительно приводит к очень медленному ощущению приложения. Для справки, вот время работы командной строки:

  • hg status: 4,573 секунды
  • hg incoming: 12,150 секунд

Кажется, что время командной строки совпадает со временем рабочего места, но рабочее место делает задержку намного более расстраивающей, потому что это синхронно с использованием программы. Например, типичная задача - «получить последние материалы, которые только что выдвинул мой коллега». Выглядит это так (округляется только время, проведенное на компьютере):

  • Open TortoiseHg: 10 минут.
  • Откройте соответствующий репозиторий, дважды щелкнув в реестре репозитория: 5 секунд.
  • Фиксация локальных изменений, которые требуют фиксации:
    • Нажмите «Рабочий каталог»: 5 секунд.
    • Выберите важные файлы и введите сообщение фиксации.
    • Нажмите фиксацию: 20 секунд.
  • Получить изменения сотрудника:
    • Проверка входящих изменений: 10 секунд.
    • Просмотрите их.
    • Принять входящие изменения: 40 секунд.
  • Полка не готовых изменений:
    • Диалог открытия полки: 2 секунды.
    • Хранить оставшиеся файлы: 6 минут
    • Обновление: 5 секунд.
  • Объединить:
    • Нажмите на другую голову: 3 секунды.
    • Слияние с местным:
    • Ожидание «чистой» проверки: 15 секунд.
    • Ожидание объединения (при условии отсутствия конфликтов): 10 секунд.
    • Фиксация: 30 секунд.
  • Нештатные изменения:
    • Диалог открытия полки: 2 секунды.
    • Отключение: 6 минут.
    • Обновление: 5 секунд.

Итого: 24 минуты 32 секунды.

Двенадцать из этих минут тратятся на откладывание и хранение. Десять тратятся только на открытие. Одним из следствий этого является то, что люди склонны совершать вещи, которые, как они не уверены, пойдут куда-то только для того, чтобы избежать стоимости стеллажей. Но даже если вы не предполагаете, что у вас нет стеллажей и нет затрат на открытие (может быть, вы просто оставляете его открытым), вам все равно потребуется 2 с половиной минуты кропотливого щелчка, чтобы получить последнюю информацию.

И это даже не относится к более важным вещам, таким как клонирование и еще много чего. Все так медленно.

У меня есть:

  • Отключен антивирус.
  • Индексирование отключено.
  • Rebooted.
  • Пробовал на 3 разных версиях windows.
  • Пробовал на разных аппаратных средствах, в большинстве своем с приемлемым качеством: Core 2 Duo @ 3,16 ГГц, 8 Гб Ram.
  • Пробовал на 32 и 64 битных ОС.
  • Пробовал отключить его от сети.

Репозиторий на самом деле представляет собой два репозитория: основной репо и суб-репо, который содержит все наши сторонние двоичные файлы. Папка .hg основного репо составляет 676 МБ. Папка .hg суб-репо составляет 641 МБ. Содержание default в первичном репо составляет 7,05 ГБ. Содержимое default в суб-репо составляет 642 МБ. Средний размер файла в основном репо составляет 563 КБ. Максимальный размер файла в основном репо составляет 170 МБ. В основном репо 13 438 файлов. Средний размер файла в суб-репо составляет 23 КБ. Максимальный размер файла в суб-репо составляет 132 МБ. В суб-репо 57087 файлов.

У меня включены расширения "большой пуш", "caseguard", "fetch", "gestalt", "kbfiles", "печка", "kilnauth", "kilnpath", "mq", "purge" и "трансплантат".

Есть идеи, где начать выяснять, как ускорить процесс?Медлительность сводит нас с ума.

Ответы [ 3 ]

28 голосов
/ 26 октября 2011

Хорошо, отвечаю на свой вопрос, потому что я нашел ответ, следуя совету Тима.

Виновник kbfiles от FogCreek.Отключение этой статистики уменьшилось с 12 до 0,7 секунд.Кроме того, графический интерфейс открывается быстрее, чем я могу время.Повторное включение заставляет все снова резко замедлиться.

Не похоже, что в медленных вещах можно обвинить kbfiles, но худшее из этого может.(В частности, полка все еще довольно медленная - загрузка ЦП. Мы можем обойти это, хотя.)

2 голосов
/ 25 октября 2011

Это тонна файлов ... и некоторые из них очень большие. Как это работает без больших файлов? По моему скромному мнению, двоичные файлы - не самая лучшая вещь для отслеживания с помощью hg / git.

Как насчет разбить большой репо на более мелкие. Они действительно должны быть в 2 ОГРОМНЫХ репо?

Может быть, дефрагментация на жестких дисках может немного улучшить некоторые из этих времен. Также посмотрите на расширения, которые были созданы, чтобы помочь иметь дело именно с большими двоичными файлами. Смотрите здесь:

https://www.mercurial -scm.org / вики / HandlingLargeFiles

1 голос
/ 08 ноября 2018

В некоторых случаях совет , приведенный в документации , может быть полезен для улучшения скорости THG:

5.4.8. Последствия для производительности

Существуют некоторые функции Workbench, которые могут влиять на производительность в больших репозиториях.

Вид ‣ Выбрать столбцы журнала…

  • Включение столбца Changes может быть дорогостоящим для расчета в репозиториях с большими рабочими копиями, , что приводит к замедлению как обновлений, так и прокрутки .

Просмотр ‣ Загрузить все

  • Обычно, когда пользователь прокручивает историю, куски наборов изменений читаются при прокрутке. Этот выбор меню позволяет Workbench считывать все наборы изменений из хранилища, вероятно, , что позволяет более плавно перемещаться по истории .

По моему опыту, это определенно стоит делать! Вы должны хотя бы попробовать их и посмотреть, есть ли заметный эффект.

...