Vlákno názorů k článku OpenOffice.org 2.2: pro lepší vzhled dokumentů od Clock - V Jave? C++? Nebo co ji dela tak...
-
anonymníCelkem dost asi taky zalezi na pameti. Ono to neni obecne extra pomale, ale je to znatelne pomalejsi nez MSO nebo jine aplikace. Misty dokonce tak na hranici uzivatelsky privetive kancelarske aplikace.
Jinak jsem to uspesne provozoval i na 400MHz+320MB RAM a slo to, ale proste to chtelo trochu trpelivosti. -
Sid (neregistrovaný)Mozem sa spytat s akou poslednou verziou javy ste ste sa stretol? Tipujem tak 1.2. Nechapem aky zmysel maju taketo prispevky ako vas - dokazat ze nieco je jediny "pravy" jazyk? - ano java gui bolo kedysi celkom pomale ale skuste napr verziu poslednu verziu 1.6 a myslim ze budete celkom prekvapeny.
-
anonymníNejde o jazyk, ale o JVM.
Multiplatformnost je proste vyvazena nizsim vykonem. A zejmena GUI v Jave si hlavne z pocatku hodne uskodilo tim, ze bylo hodne spatne a hodne pomale (a hodne osklive :)).
Urcite se to posledni dobou zlepsuje, ale porad je to pro strovnatelne aplikace jenom 'uz mozna skoro stejne rychle' jako nativni aplikace. -
Viktor (neregistrovaný)Prave ze ide o JVM. Multiplatformnost nie je problem, skor to ze Java je interpretovana. JVM od Sunu ma ale Hotspot kompiler, to znamena ze casto pouzivane casti kodu su optimalizovane a kompilovane pocas run-time do nativneho kodu. V konecnom dosledku to znamena ze program v Jave je v urcitych miestach nie pomalsi, ale rychlejsi ako taka ista implementacia trebars v C. Je to logicke, optimalizacia pre program v C prebieha iba pocas compile-time, zatial co kompiler v JVM ma omnoho viac informacii o prave spracuvanom kode, a tak moze robit agresivnejsie optimalizacie. Program v Jave ktory sa teda nezmeni, bude kazdou dalsou verziou JVM fungovat rychlejsie.
-
anonymnía kdo tvrdi, ze to je jeho chyba?? :)
proste kazdy programovaci jazyk odpovida nejakemu prostredi a to zase nejake mnozine aplikaci pro ktere je vhodne
nikdo v jave nebude psat ovladace pro hardware ale zase v cecku tezko bude nekdo psat enterprise aplikaci
desktopove aplikace je ta hranice, kdy to jde v obojim a pak zalezi i na ostatnich preferencich autora -
Ivan (neregistrovaný)Ja zrovna myslel, ze za pomalost OO muze dedictni StarOffice. Zkousel jsem kdysi prvni buildy pro linux jeste kdyz to bylo komercni a prislo mi, ze to cely bezi nad emulatorem windows. Teda ne ze by to pouzivalo wine, ale ze si to samo implementuje spoustu
wokennich knihoven. Takze nakonec cely office bezi nad vlastnim wrapperem, kterym bezi nad knihovnami linuxu. Za pomalost OO urcitge nemuze JAVA, bez ni je to stejne pomale jako s ni. -
anonymníJo to bylo pekne hnusny. Melo to vlastni plochu, vlastni taskbar, dokonce i vlastni tlacitko 'start'. A to vsechno to provadelo dokonce i ve windows.
Mozna by to vazne chtelo na chvili pozastavit nove featury (hlavne vizualni jako kerning) a misto toho vyresit zname bugy a konecne to uz trochu urychlit. -
m0rph (neregistrovaný)V zajmu ferovosti je vhodne zminit, ze problem neni jen na strane OOo:
http://go-oo.org/~michael/OOoStartup.pdf -
Ivan (neregistrovaný)Ten clanek neni o kompilatorech, ale o exec. formatu ELF a o relokaci symbolu pri spousteni
aplikaci. Dekuji za odkaz netusil jsem ze s dyn. linkovanim je to az tak spatne. Na druhou
stranu to vysvetluje proc aplikace bezici pod monem, vypadaji na prvni pohled rychlejsi nez gnome aplikace napsane v Ccku. Zmeny v ABI C++ bych se nebal, ABI se meni tak casto ze by si toho ani nikdo nevsimnul :) -
Nevznikla presene z tohoto duvodu uprava DT_GNU_HASH?
http://sources.redhat.com/ml/binutils/2006-06/msg00418.html
