В Eclipse 3.5 (и новее) вкладка переключения очень медленная - PullRequest
41 голосов
/ 26 июня 2009

Я использую eclipse 3.5 (сборка какао) на Macos 10.5 с Java 1.5.0.19.

У меня только 3 открытых файла java 1 файлов ~ 2000 строк остальные 2 ~ 700 строк.

Но когда я переключаюсь с одной вкладки файла на другую, затмение занимает много времени (~ 20 секунд), чтобы перейти на другую вкладку.

Я уже изменил eclipse.ini на

more eclipse.ini
-startup
../../../plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.0.0.v20090519
-product
org.eclipse.epp.package.jee.product
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=512m
-Xms128m
-Xmx1024m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts

Есть ли способ ускорить затмение 3.5?

Спасибо.

Ответы [ 14 ]

52 голосов
/ 26 сентября 2009

Я переключил эту строку в файле eclipse.ini (находится в пакете приложения eclipse):

-Dosgi.requiredJavaVersion=1.5

до

-Dosgi.requiredJavaVersion=1.6

и переключение вкладок снова было быстрым.

3 голосов
/ 26 июня 2009

Пойдите с 32-разрядным выпуском Какао. ИМХО 64-битная не поможет. Это действительно прекрасно работает на моем 2,4 ГГц MBP. У меня обычно открыто около 30 файлов, некоторые довольно большие, никогда не испытывали того, что вы описываете.

Попробуйте получить новый простой ванильный 32-битный дистрибутив Cocoa, не изменяйте ничего и проверьте, есть ли проблема. Это может быть и плагин-изгой. У вас есть какие-либо установленные?

Проверьте состояние кучи. Откройте настройки Eclipse, на самой первой странице настроек есть опция «показать состояние кучи». Возможно, вам не хватает памяти. Проверьте состояние обмена вашей машины с помощью монитора активности - если он много поменяется, я бы порекомендовал закрыть другие приложения. В общем, я рекомендую 4 ГБ оперативной памяти для разработки машин.

2 голосов
/ 05 декабря 2012

Сейчас есть исправления для Juno, чтобы начать решение этой проблемы. См. комментарий # 212 об ошибке 385272 для получения информации о том, как обновить вашу установку. Если вы подождете немного дольше, вы найдете эти исправления в вехе в Kepler 12/21/2012.

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

2 голосов
/ 23 сентября 2012

Я знаю, что это немного поздно для игры, но я обнаружил, что изменение разрешений на ~ workspace.metadata.plugins \ org.eclipse.e4.workbench, чтобы запретить себе доступ, остановило проблему замедления.

Кажется, что Eclipse (4.2.0) время от времени записывает поврежденный файл настроек, и когда он снова загружается при запуске, он все замедляет, так как постоянно выдает ошибки изнутри. Изменение безопасности в этом каталоге, чтобы Eclipse не мог писать в него, является своего рода «исправлением»! Это означает, что каждый раз, когда Eclipse запускается, он возвращается к настройкам по умолчанию, но если скорость важнее, я думаю, что это достойная жертва.

1 голос
/ 21 сентября 2012

Увеличение пределов памяти в eclipse.ini, кажется, исправило это для меня - не уверен, останется ли оно исправленным, хотя

FROM:

-vmargs
-Xms40m
-Xmx512m

К

-vmargs
-XX:MaxPermSize=512m
-Xms256m
-Xmx784m

ТАКЖЕ - если вы пришли из aptana3 и импортировали свой проект - вам нужно сделать это

  1. Нажмите Свойства проекта
  2. Перейти к «Строителям»
  3. Убедитесь, что «пропавших строителей» нет, если они есть, снимите их - у меня осталось два от aptana, когда я импортировал свой проект (com.aptana.ide.core.unifiedBuilder И com.aptana.editor.php. aptanaPhpBuilder)

---- ОБНОВЛЕНИЕ ----

Это было исправлено - , но не по причинам, которые я думал . Мой SVN больше не был распознан затмением. Как только я нажал «поделиться с командой» и снова подключил его, снова появились проблемы с переключением вкладок. Я собираюсь попытаться выяснить, является ли это проблемой svnKit против JavaHL - я не уверен, какой разъем Я выбрал, когда я настроил затмение на этот раз.

Если вы хотите подтвердить, что это ваша проблема, пытаясь отключиться от SVN (Team-> disconnect) и перезапустить eclipse

1 голос
/ 18 августа 2012

Этот отчет об ошибке затмения точно соответствует описанному вами поведению. (У меня был такой же опыт использования новой установки Juno на мощной машине XP.)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272

Самая полезная часть отчета об ошибке была в комментарии 29 , в котором предлагается создать новое рабочее пространство. Самый простой способ сделать это:

1) выходное затмение

2) переименовать ... / path / to / workspace / .metadata / .plugins / org.eclipse.e4.workbench / workbench.xmi (например, добавить ".old")

3) начало затмения

Я полагаю, что изменение -Dosgi.requiredJavaVersion = 1,5-1,6 может помочь только случайно, если вообще будет.

1 голос
/ 27 июня 2010

переключение на 1.6 действительно помогает. Это ссылка, чтобы найти файл eclipse.ini для Mac http://wiki.eclipse.org/Eclipse.ini

1 голос
/ 09 апреля 2010

Это может быть ошибка, на которую ссылались. https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229

0 голосов
/ 05 января 2017

Первоначальная проблема медленного переключения между вкладками вновь появилась в Eclipse Neon (только 4.6.2?) С использованием темы Dark .

Решение: отключить тематические полосы прокрутки в e4-dark_win.css (внизу файла): StyledText { swt-scrollbar-themed: false; [...]

0 голосов
/ 17 февраля 2013

TL; DR для потока ошибок:

http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation#Resolution

работал для меня.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...