Dotaz: Eclipse s pomalost gui

[poky74]

Ahoj,

zatoužil jsem po nějakém mocnějším ide a vydal se na cestu testování. Jako ideální (funkcemi, symatiemi, vzhledem, uspořádáním, etc..) se mi jeví Eclipse. Je tu ovšem jedna vééliká nepříjemnost a o zaškubávání gui.

Píšu si vesele kód a když to má něco obarvit nebo třeba poradit syntaxi tak to zamrzne tak na 5-10 sekund, což je velice nepříjemné.

Hledal jsem a hledal, anšel rady typu dát do konfiguráku eclipse.ini různé hodnoty (-Xmx1024m atd..) ale nepomohlo to.

Stroj na kterém to zkouším není žádný šnek (dvoujádro 2 GHz, 2GB ram), problém jsem nejdříve viděl v tom, že celý / je na sd kartě (čtění 6MB/s, zápis ještě pomalejší),a le to jsem vyřešil umístěním celého eclipsu do ramdisku, žádná změna.

Mohl by mi nějaký zkušený eclipsista poradit co s tím? Je to určitě velice kvalitní ide a nerad bych ho opustil ještě dříve než se s ním pořádně seznámím, ale to zaškubávání je opravdu velice nepříjemné.

 

java version "1.6.0_18"

OpenJDK Runtime Environment (IcedTea6 1.8.5) (6b18-1.8.5-1)

OpenJDK Server VM (build 16.0-b13, mixed mode)

 

Eclipse 3.6.1

Díky

---

---

Odpovědi

[poky74]

Dodatek, ten "zámrz" je způsoben vytížením procesoru na 100% po dobu zámrzu, což moc nechápu, když Eclipse je běžně provozován i na mnohem slabších strojích..

[l4m4]

To vypadá jako standardní výtuh během garbage collection...

Ale eclipse nepoužívám, takže řešení neporadím.

[poky74]

me to delalo to samy, nainstaloval jsem vm od sunu a jede to ok

[poky74]

 

java -version

java version "1.6.0_24"Java(TM) SE Runtime Environment (build 1.6.0_24-b07)

Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)

Bohužel, nepomohlo

[Filip Jirsák]

Zkuste použít nějaký garbage collector optimalizovaný pro interaktivní použití, třeba -XX:+UseConcMarkSweepGC. Pokud to nepomůže, asi by chtělo třeba přes jconsole zjistit, na čem se to zasekne.

Jinak 2 GB RAM na moderní javovské IDE mi připadá na hranici jestli už ne pod ní, rozhodně bych od toho nečekal nějaké pohodlí.

[poky74]

Použítí -XX:+UseConcMarkSweepGC nepomohlo.

Prolbém s pamětí nebude, při spuštěném eclipsu mi ještě 1,2GB zbývá.

Ovšem pokud otevřu čistý soubor a píšu si tak eclipse vesele rychle doplňuje vše možné, bez jediného záseku.

[Filip Jirsák]

Prolbém s pamětí nebude, při spuštěném eclipsu mi ještě 1,2GB zbývá.

To je ale dané limitem na velikost použité paměti. Zkuste jej zvýšit.

Jakým způsobem parametry javě předáváte? Eclipse se myslím spouští nějakým nativním spouštěčem, který si bere parametry např. z eclipse.ini, nevím, zda je možné předat mu je nějak i na příkazové řádce. Zkuste se pomocí jconsole podívat, s jakými parametry se skutečně spustila JVM. A při té příležitosti můžete také rovnou vyzkoušet, zda ty záseky způsobuje opravdu GC, nebo něco jiného – podívejte se jednak na aktivitu GC, jednak na vlákno zpracování událostí, zda nečeká na nějaký zámek.

[poky74]

Ty čísla okolo paměti jsem opět zvýšil, nepmohlo. Při spuštění eclupsu v debug módu to ukazuje že si ty údaje o paměti bere z eclipse.ini, neustále mi po spuštění zvývá 1,2GB volné paměti.

Snažím se někde vyštrachat tu jconsoli, ale na disku není, v repozitářích také ne, kdepak bych jí našel prosím?

[Filip Jirsák]

Je to součást JDK i JRE, určitě těch Sunu. Např. při instalaci do /opt/ je v adresáři (dle verze) /opt/sun-jdk-1.6.0.22/bin/jconsole, např. Gentoo ji pak přes mechanismus java-version dává i do /usr/bin/jconsole.

[poky74]

Opravdu to nikde není k nalezení, mám jre ze sránek oraclu..

[Filip Jirsák]

Aha, omlouvám se za zmatení, já jsem koukal do JRE, které je uvnitř JDK. A tam to je (aspoň u mne). V čistém JRE to není.

[poky74]

Opravdu nevím co dělám špatně, stáhl a nainstaloval jsem jdk ze stránek oraclu, ale locate nic jako jconsole nenajde...

[moira]

Jen mě napadlo - když jsi nainstaloval JDK mimo balíčkovač (teda předpokládám), víš jistě, že Eclipse používa toto stažené JDK a ne pořád to OpenJDK?

[Filip Jirsák]

Jakou verzi a architekturu?

[Šangala]

Doplňující otázka: jakým jazykem píšete?

[poky74]

Nyní v php

[Šangala]

Na čem je uložený ten projekt? Dělá vám to jen PHP (jestli tedy vyvíjíte i v něčem jiném :) )?
Aktivoval jste podporu JavaScriptu při vytváření projektu?, jak velký máte projekt? (Pokud ano, zkuste to bez toho)
Zkusil jste menší projektíček? :)
Kolik Vám to bere RAM, a jaké vyžití vám to ukazuje vpravo dole?
(Pokud to tam není, tak Windows −> Preferences −> General 'Show Heap status', pokud se to neobjeví, tak UnCheck, Apply Check, Apply :))
Pro PDT (PHP) zkuste nastavit alespoň (máte-li méně) - ještě trochu více není špatné, ale hodnoty 1GiB a víc jsou pro PDT scestné (jen osobní zkušenost):

-XX:MaxPermSize=256m
-Xms40m
-Xmx384m

je to v eclipse ini, v místě spouštěcího scriptu.
Přijde mi to taky v posledních PDT v Heliosu, nějaké né-úplně-ok, že tam běží něco obtížného :). PS: Pokud už máte tam to dole v pravo, lze tam i vyvolat Garbage col., tak můžete zkusit jak dlouho u to trvá :)

[poky74]

Ten projekt byl uložen na sd kartě, stejně jako "workspace". Obě jsem přesunul do ramdisku, myslím že se to o něco zlepšílo, ale tak o 10%...

Hodnoty v eclipse.ini jsem nasatvil dle vašeho vzoru, zapnul ten heap status, ukazuje cca "58M of 98M".

V menším projektíčku (jen pár desítek řádků dlouhý php soubor je odezva téměř okamžitá), ale jakmile to jde na cca 800 řádků a více tak už to zahuhává na několik vteřin..

[poky74]

Oprava, oba jsem přesunul do tmpfs, stejně jako je složka s eclipsem.

[Šangala]

"58M of 98M" - tím to trochu říká, že nedostatkem paměti to nebude… :)
, Jak říkám v PDT je něco shnilého, schválně jsem si to vyzkoušel, sice mi dalo zabrat abych našel PHP script o délce 800 řádků, ale jeden jsem v projektu s 1631 soubory našel má přes 900 řádků a zhruba od 600 to začíná zpomalovat a začíná to být na.íra.í.
Takže problém je v délce souboru ne, velikosti projektu. S CDT, tedy s cpp zdrojákem ani s 1000 řádky žádný problém.
Netbeans 6.8 z výše uvedeným PHP scriptem žádný problém - hnije to v PDT :(.
Já mám „hlavní“ PHP-ko ve virtuálu ve VmWare ale starší (Open Suse 10.2 a Eclipse Europa 3.3.0), takže jsem si toho sice všiml, ale obvykle nemám tak dlouhé php soubory, takže mě to nějak neobtěžovalo.

Toš fčil jsem pro jistotu vykopíroval tuto starší verzi do hlavní mašiny (Debian Lenny 64bit), přidal sun Javu 32bit 1.5 (bo to je třeba pro verzi 32bit :) ), spustil s parametrem vm a vlastně Vám musím poděkovat, to je jiná - to se prostě musí zkusit :).
Napadlo mě x86 vs. x86_64, tak jsem začal stahovat „32bitovou šmejárnu“ Helios-e a uvidím
Zkuste jít pozadu po verzích - moje je dost historická (nicméně na PHP tam nesleduji žádný výrazné přidání funkcionality, jen matoucí možnost detailnějšího nastaveni syntaxe coloring):
http://wiki.eclipse.org/Older_Versions_Of_Eclipse
http://www.eclipse.org/downloads/packages/release/galileo/sr2

[Šangala]

Takže jsem to stáhl a hle „32bit šmejďárna“ už nezlobí tak moc s PHP souborem delším 900 řádků.
Nevím čím je to způsobeno, jsou 3 možnosti:

• 32bit prostě funguje lépe
• Stažená verze je 3.6.2 a něco se tam opravilo
• Fčil jsem stáhl přímo balíček PDT a před tím to bylo CDT a podporu PHP jsem přidával až v Eclipse

Tak: stáhl jsem update přímo z Eclipse na verzi 3.6.2 (mé původní instance) a je to nyní lepší, ale k té „32bit šmejďárně“ ještě kousíček chybí a s Europa-ou se to nedá srovanat :) - ale stále jen PHP, u céčka furt super…
Tímto končím :)

[Filip Jirsák]

64bitová verze javy od Sunu má jiné výchozí nastavení JIT kompilátoru, limitů paměti apod. Nemůže být rozdíl v tom?

[Šangala]

Když to říkáte :), přiznám se, to nevím.
Nicméně po update už ten rozdíl mezi 32/64 není tak velký obojí je takové nějaké „tak jak java gui swing aplikace před 5-ti lety :)“ - prostě to při delším souboru váhá i se psaním (člověk to vnímá, ale jsou to určitě jen milisekundy a sem tam to trošku víc zadrhne) - no a 64bit víc, ale změřte to, aby to bylo objektivní :).
Ale když vezmu ten stařičký Eclipse Europe, tak je to jak vim-ko, ale s tím že to „nabízí“ co většinou chci.
Je pravda, že v této starší verzi to nenabízí, standardní fce PHP a statické fce a proměnné (nebo spíše jak kdy - není to dokonalé), takže by si člověk řekl „aha musí to dělat více“, nicméně když to zkouším, na popud tohoto dotazu, protože jak jsem psal, nemám obvykle tak dlouhé PHP zdrojáky, tak je to spíše úměrné (to zadrhávání) délce souboru (nebo možná počtu řádků) - jakoby to „nepřemýšlelo“ nad aktuálním řádkem, ale nad celým souborem.
Na procesoru je to vidět, že vyletí, ale nějak to rozumě odchytit…
A jak jsem uvedl jen PHP, C++, SQL, Java je OK (Javu jsem jen zkoušel na jednom delším souboru)

PS: Pro jistotu jsem nahrál stejný projekt i stejné exportované nastavení i stejné spouštěcí parametry.
     - taky to nemám bůhví-jaký šrot Core 2 Duo @2.4GHz / 4GiB RAM.

[Kartelus]

http://download.oracle.com/javase/1.5.0/docs/guide/2d/flags.html

Do startovacího skriptu přidat přepínač "java -jar" -Dsun.java2d.pmoffscreen=false (funguje vždy). Velké zrychlejí dojde u -Dsun.java2d.opengl=true, ale u mne je problém s OSS ovladačem od AMD, dělá artefakty, jinak by byla rychlost výborná (jdownloader).

[poky74]

Ahoj, přidal jsem to tam, ale nemá to žádný efekt..

[Kartelus]

Výše uvedené funguje ve spouštěcím scriptu jDownloaderu (java -Dsun.java2d.opengl=false -Dsun.java2d.pmoffscreen=false -Dsun.java2d.d3d=false -Xmx512m -jar JDownloader.jar). Právě se nimrám v Ubuntu 11.04 a v partnerským repozitáři není java od Sunu (Oracle) a nejspíš ani nebude. Vyplňování capcha pod OpenJDK bylo nepoužitelné (2s prodleva od stisku klávesy)...

Enormní problém má (nejen) Eclipse při editaci dlouhých řádků, typicky jednořádkové definice v css, případně smrtící v podobě zhuštěných jquery (.min) souborů. V takovém případě nepomůže ani voda svěcená.

Pokud nepomůže trik s -Dsun.java pro OpenJDK, případně ani nainstalování Sun JDK (a zároveň odinstalování OpenJDK), pak asi nepomůže nic.