Затмение становится медленным, когда проект содержит много ссылок (причина: плохой сетевой ресурс в пути сборки)

Question

В одном из наших приложений есть один проект Eclipse, который содержит весь код.Я думаю, что это довольно много кода - не маленький проект, но и не огромный.Я провел небольшую проверку и получил:

Найдено <4245> файлов кодов
Всего <421557> строк кода

Эта проверка включает любые строки кодакоторые не пусты или просто содержат { или }.

Так что это не большой проект - однако, .project определяет много ссылок, чтобы замаскировать реальную структуру каталогов, чтобы создать другое представление дляPackage Explorer - так проект станет более понятным.

Проблема в том, что eclipse работает очень медленно в некоторых областях.
Примеры:

• Поиск ссылокв рабочей области ( Ctrl + Shift + G ) - занимает очень много времени по сравнению с предыдущими проектами, над которыми я работал, в такой степени
• декомпиляциячерез jadclipse или JDEclipse это может занять до 1 минуты - в результате eclipse отобразит прекрасный суффикс (не отвечает) в строке заголовка.Тот же код, декомпилированный извне eclipse, занимает менее секунды.
• Выполнение теста JUnit - инициирование выполнения занимает более 10 секунд, в которых eclipse, кажется, не делает ничего важного.

Есть идеи, почему это может произойти и может ли это быть результатом "сложной" структуры проекта?

Использование eclipse 3.6 без установки множества плагинов.

РЕДАКТИРОВАТЬ:

Использование resmon в конечном итоге показал мне проблему.Я заметил, что eclipse продолжает пытаться подключиться к общему сетевому ресурсу - для этого не потребовалось много ресурсов процессора или ввода-вывода, но все же он был там.При проверке файла .classpath я заметил следующее:

<classpathentry kind="lib" path="build_class" sourcepath="some share using samba ..."> 

Общий ресурс, на который мы ссылались, даже не был правильным путем, но это, вероятно, вызывало много накладных расходов в каждом действии.

Извлеките вложение sourcepath и оставьте его как:

<classpathentry kind="lib" path="build_class"> 

Решил проблему немедленно.Так как мы использовали плагин декомпилятора, это изменение не повредило нам.

Answer 1

Это типично для ситуации с одним или несколькими узкими местами ресурса.

Вам нужно будет изучить с помощью инструментов операционной системы, что ждет Eclipse (диспетчер задач и perfmon отлично подходят для Windows), и если это не поможет, исследовать сам Eclipse с помощью jvisualvm в Oracle 6 JDK.

Скорее всего, вы обнаружите, что система ожидает базовый жесткий диск. Это может иметь несколько причин, некоторые из которых:

• Eclipse - большая программа. Операционная система может потребоваться перенести ее части на диск. Для Eclipse это разрушает производительность. Действительно!
• Eclipse требуется лот доступа к диску. Если у вас медленный диск или (ужас ужасов) чрезмерно агрессивная антивирусная программа, это также снижает производительность. Если в операционной системе достаточно свободного ОЗУ, она может кэшировать файлы в памяти, обеспечивая более высокую производительность.

Если это так, получите больше оперативной памяти.

Если базовая система работает нормально, но Eclipse сам по себе очень медленный (но другие программы Java работают нормально), то посмотрите с помощью jvisualvm, как со временем ведет себя использование памяти, и если у вас много частых сборок мусора, когда вы нужно подождать, вам может понадобиться выделить больше памяти для JVM. Это делается в файле eclipse.ini.