Предложения по оптимизации EGit на Eclipse

Я использую EGit для довольно большого и сложного набора Java-проектов (более миллиона строк кода) и десятилетней истории.
Здесь я столкнулся с серьезными проблемами производительности с EGit, поскольку даже небольшое изменение одной строки в файле Java заставляет EGit повторно индексировать в течение нескольких минут, что замедляет работу всей системы. В самом деле, даже командная строка git немного медленная, так как "git status" занимает около минуты из командной строки, но я могу смириться с этой проблемой производительности и медленным диалогом фиксации EGit (ссылка). Поскольку я могу использовать командную строку git для фиксации и обновления, но я не хочу жертвовать своей производительностью Eclipse, поскольку это влияет на производительность.

Вот что я пробовал, занимаясь поиском в Google и опрашивая окружающих:

  1. Добавлена ​​папка всех классов в исключаемый файл. В самом деле, попытался на некоторое время поместить папку классов в .gitignore.
  2. Дали Эгиту достаточно времени, чтобы завершить индексацию, оставив машину включенной в течение дня.
  3. Постановка Git, история и все другие представления Eclipses закрываются в рабочей среде Eclipse во время разработки.
  4. Сделал "git gc" - это повлияло на производительность командной строки, но почти не повлияло на EGit.
  5. Непроверенный декоратор меток для Git. Настройки -> Общие -> Внешний вид -> Украшение этикеток.
  6. Удален cygwin из пути, поскольку где-то на форуме читалось, что JGit может использовать cygwin для преобразования пути.
  7. Увеличен кеш окна с 10 до 70 м в Eclipse (Настройки -> Команда -> Git -> кеш окна).

PS: Репозиторий Git указывает на удаленный репозиторий svn. Кроме того, я новичок в git, поэтому мог допустить ошибку в настройке, поэтому, пожалуйста, не стесняйтесь указывать на что угодно.

Вот моя системная информация, у меня нет особых технических характеристик оборудования, но есть запасная оперативная память (8 ГБ).

  • git-gui версия 0.16 GITGUID
  • версия git: 1.7.10.mysgit.1
  • JDK 1.6_025
  • Версия Eclipse: 3.7.2 версия Java EE с параметрами -Xms1536m -Xmx1536m
  • ЭГит: 1.3.0.201202151440
  • Процессор Windows 7: Core 2 Duo 2,6 ГГц

git eclipse egit
person Hemant    schedule 21.04.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Это проблема между CVCS (централизованная VCS) и DVCS (распределенная) VCS:

  • Одно репо SVN может содержать данные объемом в ГБ.
  • репозиторий Git должен быть небольшим и использовать преимущества подмодулей, чтобы представлять через несколько репозиториев Git.

Я подозреваю, что многие репозитории могут работать лучше, чем одно гигантское репо Git. В противном случае начнут возникать проблемы с синхронизацией, как в случае с ошибкой 323839.

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

person VonC    schedule 21.04.2012
comment
VonC - Согласитесь, но с реализацией Egit наверняка есть некоторые проблемы, так как тот же большой репозиторий git довольно хорошо работает в Linux с IntelliJ), хотя я согласен, что файловые системы Linux намного быстрее. Итак, могу ли я создать одно центральное репозиторий Git, которое является клоном SVN, а затем иметь несколько небольших репозиториев Git из гигантского центрального репозитория Git? - person Hemant; 24.04.2012
comment
@Hemant нет, вы не можете (не с возможностью возврата в репозиторий SVN). Вы можете определить одно репо Git, которое объявляет все маленькие как подмодули, но не будет никакой связи с репозиторием SVN. Остается механизм ручной синхронизации. - person VonC; 24.04.2012
comment
Vonc - Спасибо, что разъяснили. Я продолжу изучать свои варианты ... также я надеюсь, что команда Egit быстрее настроит производительность. - person Hemant; 24.04.2012

arrow_upward
3
arrow_downward

Вероятно, это не совсем ваша проблема, но эта страница появляется в Google в отношении производительности egit. Как только источник проблем с производительностью остается неотслеживаемыми (индексированными?) Файлами. Убедитесь, что у вас нет большого количества неотслеживаемых файлов в дереве локальных каталогов, поскольку это серьезно влияет на производительность egit. Я удалил директор с более чем 10 КБ файлов, и производительность фиксации увеличилась с 1+ минуты, чтобы открыть диалоговое окно фиксации, до пары секунд.

person Brett Sutton    schedule 21.11.2012
comment
В моем репозитории нет неотслеживаемых файлов. Я работаю над огромным репозиторием, в котором есть около 28 тыс. Файлов Java и 136 тыс. Коммитов, но большинство из них уже должно быть упаковано. - person Hemant; 22.11.2012
comment
Попробуйте клонировать git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. В проверке ядра Linux содержится около 45 тыс. Файлов, а в ядре - более 300 тыс. Коммитов. Репо с 28 КБ файлов и 136 КБ коммитов - большое, а не огромное. - person Mikko Rantalainen; 11.07.2014
comment
Чтобы получить огромное количество репо, попробуйте клонировать https://github.com/mozilla/gecko-dev.git. Клону нужно будет передать около 1,5 ГБ данных только по проводам ... - person Mikko Rantalainen; 11.07.2014
comment
В кассе репозитория Mozilla / Gecko 97 тыс. Файлов (681 МБ исходных файлов) и 370 тыс. Коммитов. При использовании 64-битной Ubuntu на жестком диске (вместо SSD) git status занимает около 0,4 секунды с горячим кешем и 31 секунду с холодным кешем (после выполнения echo 3 > /proc/sys/vm/drop_caches от имени пользователя root). Выполнение git diff занимает 0,15 секунды после изменения отдельного файла в рабочем каталоге. git checkout -b test занимает 0,7 секунды, git add -u - 0,3 секунды и time git commit -m test. Если что-то локальное занимает 60 секунд с git, вы делаете это неправильно или вашу операционную систему нужно исправить. - person Mikko Rantalainen; 14.07.2014
comment
Вышеуказанные показатели производительности относятся к командной строке git version 1.7.9.5. Я почти уверен, что EGit не справляется с такими большими репозиториями. - person Mikko Rantalainen; 14.07.2014