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

• #1567 thon73 tag WonderCSabo #1566

  Új Válasz 2014-01-19 11:58:29 #1567

  Ú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 WonderCSabo #1566 üzenetére

  A file indexelve van, és az indexek sorba rendezve. De a szabadszavas keresésnél meg kell nézzem, hogy melyik indexnél kezdődik ugyanígy a bejegyzés. Ezzel egyébként nincs is gond, a rendezettség miatt rohadt gyorsan kikeresi a megfelelő bejegyzést.

  Eredetileg RandomAccessFile segítségével oldottam meg az egész beolvasást, mivel az könnyen pozícionálható (csak nem pufferelt beolvasást csinál.) Itt javasoltátok, hogy a szabványos read... metódusokat használjam,, mert az is pozícionálható, egyúttal pufferelhető is. (((Hozzáteszem, a RAF ráadásul elég érdekesen (halasztottan) működik, ami egy kicsit megnehezítette, hogy a file véletlen módosulását az időpont ellenőrzésével figyeljem...)))

  Szóval ezt a read dolgot építeném be, mert több szempontból is jobbnak tűnik. A BufferedReader wrapper osztályban meg lehet adni a puffer méretét (gyárilag 8192). Azt nem látom át, hogy nekem ilyen rövid beolvasásokkal van-e értelme a BufferedReader-t használni, és ha igen (mert gondolom, csak egy egységnyit tud fizikailag beolvasni a rendszer), akkor van-e értelme a 8192-t lecsökkenteni? És tovább: ha igen, mekkorára?

  Bocs, ha előbb félreérthető voltam, nem az egész file-t akarom pufferolni, csak az előolvasást. Ill. nem akarom, csak lehet, h. célszerűbb. (((Beolvasások: ListView-ban egymás utáni rekordok, darabonként kb. 30-300 karakter, de talán egy sincs 1000 felett. Keresésnél: 10-20 db 1-5 karakter hosszú beolvasás különböző helyekről, majd a megtalált rekord a fenti módon.)))

  Amit eddig a doksikban olvastam, az elég általánosan fogalmaz, és nem is magyarázza el a miérteket.
  [Ja, és még egy: sqlite-tal is kipróbáltam, de ekkora méret több sebből vérzik, jobb lett a saját adatbázis]

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