Portál AbcLinuxu, 6. května 2025 17:45
Zajimalo by mne par cisel (na ktere se celkem nepochopitelne LL nezeptal...) pokud nejsou tajna: pocet requestu za den, ve spicce a pripadne rozlozeni z hlediska agregace (teba 1% ze vsech sledovanych serveru dela 90% requestu apod.) a celkovy pocet sledovanych serveru. Bez alespon techto cisel si clovek tezko udela predstavu.
A dalsi vec je skalovatelnost, lze to rozlozit na vice stroju (nejen DB a ostatni, ale treba i samotny agregator na vice masinach apod.)?
Jinak pokud duvodem k pouzivani NFS/SMB je sdileni DB tak mi to pripada jako hodne sverazne reseni.
Samozrejme, pokud bych v C++ udelal new() na kazdy objekt zvlast, budu mit stejnou spotrebu jako javovsky vector, ale proc bych to delal kdyz mam STL vector?Muzu se zeptat, cemu pripisujete vetsi spotrebu pameti? Je to vetsi rezii datovych objektu nebo tim, ze u Javy lezi v pameti pomerne dost mrtvolek?
tot vecne dilema.
Schvalne srovnejte pocet utoku pres stack overflow na javove a C aplikace.
Az to Sun zoptimalizuje tak, ze start desktopovych aplikaci nebude vice nez o 20% pomalejsi nez nativni aplikace, tak to bude prulom javy i na desktop. Uz ted pouzivam denne nekolik GUI aplikaci v jave a takove IDE, to je pekny bumbrlicek Zvlaste kdyz mate projekt s tisici tridami.
, radsi zustanu u oskliveho vimu
29.11.2004 21:31
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
Tym narazam na x verzii prekladaca Cka, exoticke OS dependent kniznice ala VCL a podobne. Samozrejeme pripustam, ze v jave je tiez mozne takto orientovane aplikacie/kniznice vyrabat, no pri beznych veciach ako GUI, sockety, File access, DB access a podobne sa to nedeje. Ak si ale spomeniem na autoconf madness - myslim, ze je to naozaj niekde inde
Urobia si klbko strong referencii, ktore GC len ztazka rozmota a mame to... Ale aj tu je treba jazyk poznat, pripadne mat "spravny" navrh, ale to je uz o ludoch, ktori ho pouzivaju (WeakReferencie)
Java je ve vyuzivani pameti naprosto neefektivni...Zalezi jak na co. JRE samozrejme uz umi recyklovat objekty a podobne finty. Nekdy se GC muze i hodit a urychluje beh aplikace - zejmena jeji ukonceni. Proste to co jste napsal neplati vzdy. Urcite neni zcela spravne vytvoret hloupe 50 tisic objektu. Jak jste podotknul, neni to vhodne ani pro C++, natoz pro Javu. A uz vubec nechapu, co se snazite resit pomoci kontejneru Vector, ktery je pochopitelne i v Jave. Jestli myslite nejakou linou inicializaci, tak tim se nic neresi. Nerelevantni je tvrzeni, ze se (Java) proste neda srovnavat s aplikacemi, kde se vytvori statisice objektu. Java je objektove orientovany jazyk, proste se v ni vytvari tisice, desetitisice i statisice objektu. To je proste tak. A ze i velike programy jsou dnes napsany v Jave (nejen CAD, hry nebo databaze) je myslim kazdemu jasne. Doporucil bych Vam nejakou knihu o optimalizaci Javy, nez zacnete "srovnavat". Zacit muzete manualovou strankou JRE, protoze staci napriklad jen par parametru (nastavit spravne HEAP) a ejhle -- neswapuje to. A kdyz mate zkusene programatory, kteri vedi, jak programovat (v Jave), muzete se pustit bez starosti i do nejakeho CADu.
Ad: STL Vector versus Java Vector: U STL vectoru vyuziti pameti rovna se velikost objektu * pocet objektu (+-). U Java vectoru kazdy objekt se alokuje zvlast takze je to stejne (jak jsem uz psal) jako kdyby STL udelal pro kazdy objekt new(). V praxi to znamena mnohonasobne vyssi vyuziti pameti.Prominte, ale stale tomu nerozumim. Mohl byste to vysvetlit podrobneji nebo me odkazat na relevantni zdroje? Uplne presne si uz nevybavujju, jak funguje STL Vector, ale z Vaseho prispevku predpokladam, ze pri vzniku instance Vectoru alokuje jiz nejaky prostor a v nem vytvori nekolik (napr 50) instanci pozadoveneho objektu. Ale to znamena, ze jsou objekty ve Vectoru ulozeny hodnotou a to s sebou nese jiste problemy pri pridavani. Druhou moznosti, jak si drzet objekty ve vektoru, je pamatovat si na ne odkazy. To s sebou nese jistou pametovou rezii: tak 2B na odkaz + nejaka mala rezie, ktera bude po rozpocitani na jednotlive prvky vektoru asi tak desetina bitu (nebo min, zalezi na poctu prvku a implementaci). Stale tu ale nevidim souvislost pametove narocnosti s vytvarenim objektu pojednom vs. en bloc. Muzete mi to prosim objasnit? Jinak s Vami souhlasim, ze mit aplikaci s 50 * 10^3 objektu je celkem normalni. V takovych aplikacich je vsak relativne malo typu objektu. V tom pripade je mozne tyto objekty recyklovat misto mazat a znovu vytvaret. Jiste je to prace navic (pokud to jiz nepodporuje VM), a v tom pripade je na zvazeni, zda je pracnejsi obejit se bez vymozenosti Javy nebo muset delat v Jave vlastni recyklaci. Co se tyce poctu programu typu GIS, CAD, ale i office napsanych v jave: myslim, si, ze Java je z pohledu techto programu velmi mlada -- v tom smyslu, ze zacala byt pro tyto ucely pouzitelna teprve pote, co tyto programy meli za sebou jiz nekolik uspesnych komercnich verzich (a jsou tedy napsany napr. v C). Firma, ktera vyrabi takovyto software pak musi nutne zvazit, jestli ji prepsani programu do Javy prinese vic vyhod nez nevyhod. Znamena to totiz, ze se nejakou dobu nebudou pridavat nove funkce, ze je potreba preskolit programatory, kteri pomerne dlouho dobu nebudou mit v Jave takovou vykonnost jako v C, prijmout nove programatory misto tech, co firmu kvuli jave opustili, a zaskolit je ve firemnim know-how. Prepracovat/koupit podpurne a vyvojove nastroje. A co je ze vseho nejhorsi, ze prepisovanim se nutne zavlecou nove chyby, ktere bude nutne odstranit. Osobne se tedy domnivam, ze prevedeni komercne uspesneho a rozsireneho programu z jednoho programovaciho jazyka do druheho se pohybuje na hranici pricetnosti. Proto IMHO mame tak malo programu v Jave.
kym v JAVE nemam inu moznost ako pouzit referencie. (neuvazujem ako pouzitelne nieco take: String.getBytes()...)
.
Jsem sice C/C++ a javu nehanim ale proste vidim urcite jeji slabiny na druhou stranu ma spoustu plusu.
Cau.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
2.12.2004 15:29
7.12.2004 13:29