Eclipse, как и некоторые производные от этой IDE, весьма неспешное приложение. На старом компьютере ситуация усугубляется. К тому же, обвешанный плагинами монстр способен грузиться сколь угодно долго и после этого еще и тормозить во время работы. Немного поправить ситуацию можно, поигравшись с настройками виртуальной машины для этой IDE.

Для этого лучше использовать Java-машину поновее, поэтому перед процедурой нужно обновиться, если JVM старая. В моем распоряжении имеется старенький Athlon 64 X2 TK-53 (ноутбучный процессор с 2 ядрами). Я не зря упомянул процессор, т.к. наибольшего выигрыша по производительности можно достичь, выведя сборщик мусора в отдельный поток.

Java 6 поставляется с несколькими сборщиками мусора на выбор (подробнее тут, тут и тут). Причём, насколько я понял, использовать можно только один сборщик, выполняя программу. Вкратце виды сборщиков:

• SerialGC — последовательный сборщик (опция -XX:+UseSerialGC);
• ParallelGC — throughput collector (опция -XX:+UseParallelGC);
• ConcMarkSweepGC — concurrent low pause collector (опция -XX:+UseConcMarkSweepGC);
• TrainGC — incremental low pause collector (опция -XX:+UseTrainGC). Давно не обновлялся (с версии Java SE 1.4.2), и потому его использование сомнительно;
• G1 — новый сборщик, который будет включен по умолчанию в Java 7 (опции -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC). Появился в Java6 Update 14. Штука экспериментальная, но попробовать можно, и, думаю, стоит. Подробнее о нем в PDF тут.

Среди такого разнообразия, думаю, стоит обратить внимание на ConcMarkSweepGC и G1, если процессор многоядерный, либо система многопроцессорная.

Далее я обратил внимание на параметры JVM Xms и Xmx. Первый отвечает за минимальный объем памяти, выделяемый под приложение, второй — за максимальный. Если приложение подтормаживает, то можно поиграться этими опциями. Объём памяти указывается в байтах, для того, чтобы указать мегабайты, надо приписать к числу буковку M, например так: -Xms256M. Таким образом я выделил 256 мегабайт памяти под приложение.

Ну и напоследок,  можно воспользоваться опцией Java -XX:+AggressiveOpts. Эта опция включает оптимизацию производительности Java-машины.

В результате, я добавил вот такие строчки в конфигурационный файл:

-Xms256m
-Xmx600m
-XX:+AggressiveOpts -XX:+UseG1GC

В eclipse.ini их надо дописать после строки -vmargs. В AptanaStudio.ini аналогично — после строк

com.aptana.ide.desktop.integration.Application
-vmargs

Замечу также, что, поскольку эти параметры — ни что иное, как параметры исполняемого файла java/java.exe, то их можно использовать при запуске любых, требовательных к ресурсам, приложений.

UPD: На 64-битной версии Java у меня не заработала опция -XX:+AggressiveOpts. Пришлось отключить.

Версия Java:

slayer@slayer-laptop ~ $ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)