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

• #1665 thon73 tag Karma #1573

  Új Válasz 2014-02-09 00:41:28 #1665

  Ú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

  

  thon73

  tag

  válasz Karma #1573 üzenetére

  Visszatérek egy korábbi beszélgetéshez, mert ígértem, hogy számot adok az eredményeimről (ezt egy rövid részben már megtettem). Bocs, egy kicsit hosszabb lesz, aki nem érdeklődik, ugorjon nyugodtan!
  Másrészt kicsit Java topicba kívánkozik, de mivel a mérések célja az Android felderítése volt, (no meg itt kezdtünk bele), inkább itt folytattam.

  A probléma: indexelt utf-8 kódolású fileban ugrálni (seek) ide-oda, és rövid részeket beolvasni. Az első ötlet a Reader, a második ötlet a puffer használata volt. Mindkettő jó, de az alap osztályokkal nem megvalósítható.

  fis = new FileInputStream( file ); // byte alapú beolvasás
  isr = new InputStreamReader( fis, "UTF-8" ); // már karakteralapú, dekódolt és pufferelt (fix puffer)
  br = new BufferedReader( isr ); // readLine is van, és még nagyobbra állítható puffer

  fis.getChannel().position(pos) segítségével seek megvalósítható. DE! Amíg van a pufferban elem, azt használja. A puffer nem törölhető, az available() sem implementált, amivel skippelni lehetne. Egy megoldást láttam: minden seek után újranyitni a file-t. További hátrány: a puffert teljes egészében dekódolja, ha kell, ha nem.

  Megoldás: puffereléssel és utf8 dekódolással bővített Reader osztály (én valójában a RandomAccessFile-t használok a háttérben, de FileInputStream ugyanúgy jó. A "kimenet" azonban Reader lesz.) Ez már másnak is eszébe jutott ITT, én ezt az ötletet fejleszettem tovább.

  A tesztben hátulról előre 100 byte-onként végzek lineRead()-et egy 3,8 megás, rövid sorokat tartalmazó szöveges file-ban. Az eredmények megdöbbentőek (sajnos eléggé szórnak) A nem-pufferelt (egyébként azonos osztály) 20000 ms körül teljesített. Ugyanez puffereléssel: 600-900 ms

  Kimértem a különböző pufferméreteket is (ez a szórás miatt nehezebben meghatározható). DE! Az jól látszik, hogy 500 byte puffer alatt rosszabb a teljesítmény (800-1000 ms); 500-2000 byte között a legjobb (700-750 ms), 2000 felett pedig konstansan romlik (800-900 ms).

  Ez utóbbi eredmények között lényegi különbség (szerintem) nincs, vagyis nincs értelme sokat változtatni a 8192 standard pufferméreten. (((A régi szép időkben ismert szektornyi "raw" readhez amúgy sem enged oda a rendszer)))
  A pufferelt/nem pufferelt közötti különbséget sokkal kisebbnek gondoltam. Érdekes, hogy ennek ellenére nincs pufferelésre (gyári) lehetőség RandomAccessFile esetén. 20x különbség nagyon sok.

  Ha esetleg már valaki küzdött ezzel, és megosztaná a véleményét, nagyon örülnék.

• #1574 thon73 tag Karma #1573

  Új Válasz 2014-01-19 20:49:23 #1574

  Ú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

  

  thon73

  tag

  válasz Karma #1573 üzenetére

  Igen, a mérés bennem is felmerült. Nem voltam biztos abban, hogy nincs egy konkrét elméleti adat - pl. az említett méretek, ezért kérdeztem. A mérés nagy hátránya, hogy könnyen lehet, h. ez az érték gépfüggő. Mellesleg - megjegyzem - puffer nélkül is észrevehetetlenül gyors, gyanítom, hogy pufferrel is az lesz. Tényleg igaz: nem kell talán minden lépést kimérni, azér' van a négy processzor...

  Hm. Nekem a Java és az Android teljesen új volt, C-ben programoztam előtte (ráfordított időt tekintve: hobbiszinten). Talán furcsa, de - ennek ellenére - a natív rész akkor még nagyon távolinak tűnt, egyszerűbb volt Java-ra átteni, és még akkor sokat javítottam (pontosabban bővítettem) az algoritmuson. Az eredetit amúgy se lehetett volna átteni, a PalmOS nagyon máshogy "gondolkodott". A sebességgel most nincs gondom, a teljes szöveges keresést jó lenne natívan megcsinálni, de az eddig nem volt szükséges.

  A program elkészülte után Attila megkért arra, hogy legyen bővíthető a szótár. Emiatt elég mélyen beleástam magam az sqlite-ba, most lett egy komplett front-end, ami kapcsolt táblákat is kezel. (Ez nem baj, mert egy ilyen nyilvántartó program amúgy is kellett volna, de eredetileg a szótár miatt csináltam.) Arra rájöttem, hogy ilyen speciális megoldásoknál az sqlite "kicsit" korlátozott. Az idő rövidsége miatt viszont a blog folytatására nem maradt időm, így aztán se az sqlite front-end, se a szótár doksija nem került (még) se fel, se megírásra. Szóval hiányos a "doksi", igyekszem pótolni (mert nekem is segítség), de ha bárki egy picit is érdeklődik, a kódot/adatot szívesen megosztom addig is.

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