Új hozzászólás Aktív témák

• #7070 modder aktív tag bambano #7067

  Új Válasz 2013-04-30 20:28:10 #7070

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  modder

  aktív tag

  válasz bambano #7067 üzenetére

  Ez a "túldizájnoltság" szerintem is probléma, és ettől tényleg lehet lassú valami. A Java EE-nek egyébként is az az alapelve, hogy minden specifikáció, minden egy interfész, aztán olyan implementációt teszel mögé, amit akarsz lásd: OpenJPA, Hibernate, Eclipselink JPA-ra; többféle servlet container; JSF implementációra Mojarra, Myfaces; JDBC connectors; És ezeknek persze együtt kell működniük.

  Ez egyébként szerintem nagyon jó dolog, mert választhatsz, ha az egyik nem váltja be az ígéretet, akkor ott van a másik. A különböző implementációk versengenek egymással, így elvileg egyre jobbakká válnak. Sok opensource projektnél elég komoly QA is van. És szerintem nem is itt veszik el a teljesítmény: nem a Java EE service API-k és service providerek közötti vékony interfészen, hanem a service providerek implementációjában, és a programozók hozzá nem értésében, és a túlzott absztrakcióban.

  Utóbbira példa, amikor belenéztem az activiti.org kódjába, és végigdebuggoltam egy adatbázis lekérdezést. Na ott fogtam a fejem. Volt benne struktúra bőségesen is azért, hogy az adatbázist el lehessen érni szimpla JDBC kapcsolaton keresztül, támogassa a Spring és JTA tranzakció kezelést stb... Na azt már egészségtelen volt látni és ki tudja, hogy egy olyan, sokak által használt könyvtár, mint a Hibernate nincsen tele hasonló absztrakciókkal?

  Állandóan azt sugallja mindenki, hogy milyen jó az absztrakció, mert akkor az interfész mögötti implementációt mindig le lehet cserélni, és nagyon sok végfelhasználói program is ebben a szellemben készül el. Ez az egész attitűd a Java programozóknál pont lehet, hogy a Java hasonszőrű hozzáállásából ered. Nem is alaptalan hülyeség, mert a fenti, activiti.org-os példánál haszna tényleg van: van aki Springes alkalmazásként akarja használni, van aki Java EE alkalmazásba integrálva, van aki szeretne JTA-t használni, van aki nem... végfelhasználói alkalmazásoknál pedig olykor-olykor előfordul, amikor különböző rendszereket kell összekötni.

  A másik oldalon mi van .NET-ben? Minden meg van írva a Microsoft által, ritkán kell külső library-ket használni. Az ember, amikor fejleszt, tudja, hogy mikor mihez kell nyúlnia, és tudja, hogy vagy azt a komponenst használja, vagy nagyon nyomós ok/különleges igény kell ahhoz, hogy valamilyen külső libet használjon. Amit pedig használ, az nem fog változni. Ezért absztrakcióra sincs akkora szükség. Nekem legalábbis ez az érzésem, még nem fejlesztettem .NET-ben.

  Bár ezzel még nem írtam le a Javát, a fentiek miatt én maximum 5-10% sebességvesztést mondanék .NET-tel szemben, de ez csak intuíció.

  A másik, hogy a Java-t tudni kell használni. Nem mindegy, hogy az ember LinkedList-et vagy ArrayListet használ orrba-szájba, nem mindegy, hogy Hashtable vagy HashMap. Nem mindegy, hogy mekkora függvényeket ír, mert a JIT csak függvény szinten fordít, ha ránéz, és látja, hogy ez biztony 200 sor, hülye lesz lefordítani . Nem mindegy milyen String kezelő függvényeket használ. Nem mindegy, hogy fűz össze Stringeket. Nem mindegy, mekkora objektumokat használ: például kis méretű osztályokat lehet orrba-szájba példányosítani, majd hagyni felgereblyézni a garbage collector által, mert erre van külön optimalizáció a Hotspot VM-ben. String kezelés nagyon sokat el tud venni alapjában véve.
  Akkor például, ha valaki JPA-t használ, hajlamos (én hajlamos vagyok) nem figyelni, hogy valójában hányszor fog az adatbázishoz fordulni a provider, amíg ez nincs optimalizálva, bizony előfordul, hogy egy oldal lekérdezés alatt több 10-szer is. Hogy van beállítva a cache, lehet, hogy a memória felét a Hibernate akárhanyad szintű cache-ében tárolt adatbázis objektumok alkotják.
  Akkor aki JSF-et használ, nem árt belegondolni, hogy mennyire akar külső komponens library-ket használni, mint az Icefaces vagy Primefaces. Ezek nagyon szépek, sokat tudnak, de megvan az ára is sokszor: a komponensek állapota minden felhasználói sessionre egyedileg tárolódnak, így elég sok memóriát meg tudnak enni. (azt hiszem talán ASP.NET Webforms-szal is ez volt a probléma?) Figyelni kell, hogy mit tárolunk SessionScope beanekben, mert betolni a fél adatbázist memóriába, és ott tartani a user session végéig azért, hogy feltöltsünk egy datatable-t, amit fél percig néz a user, nem túl okos ötlet. Ugyenez vonatkozik JPA-ra is: Eager fetch-csel óvatosan, nehogy pár entitásért berántsa a fél adatbázist memóriába a tranzitív eager fetch propertiken keresztül.
  Na ez csak pár dolog, ami eszembe jutott, és ami könnyen problémákhoz vezethet. Ha performance probléma van, nem egyből a nyelvet kell okolni, hanem profiling-ot kell alkalmazni, meg kell nézni, hogy mi lehet a szűk keresztmetszet. A fent leírtak közül bármi okozhat rohadt sok memóriazabálást, lassúságot.

  Na még egy gondolat, visszaugorva az esetlegesen lassú vagy optimalizálatlan service providerekhez. (mint Hibernate). Vajon jogos-e magát a nyelvet lassúnak kikiáltani úgy, hogy nem közvetlenül a nyelv lassú, hanem a köré épített platform? Szerintem jogos, elvégre a Java EE maga ezek a library-k, de nem egyértelmű, hogy ők okolhatóak ezért. Ott van például a korábban említett Cassandra, Neo4j vagy éppen a HBase, Hadoop platform, mind Javában vannak írva, és köszönik, nagyon jól megvannak és gyorsak. Jobban utána kéne járni a lassúság "sztereotípiának", hogy mi lehet az oka, és mennyi igazság van benne.

Új hozzászólás Aktív témák