C# n. sor kiolvasása

Fórumok

Sziasztok!

Egy olyan problémával állok szemben, hogy egy txt állományból kellene az n. sort kiolvasnom és nem szeretném az elejéről ciklussal végig pörgetni, mivel igencsak hosszú a sor és egy többmilliószor futó szimulációnál nem előnyös folyamatosan arra várni, hogy a megfelelő sort éppen megtaláljam az adatbázisban.

Tud valaki olyan megoldást, amivel a StremaReader-em n. sorára tudom a ReadLine-t ráengedn?

Köszi

Hozzászólások

Ez egy jó kérdés, de akkor ha mégis végig kell görgetnie, akkor is érdekelne a megoldás.
Mert a tartalmat se kellene legalább összeahasonlíttatni minden körben, illetve előről indítani is érdekes lenne, mert az sem túl jó, hogy, hamár megvan a kellő sor, akkor daráljuk végig a többit is gyorsan...
--
MacBook Black
OS X 10.6.5

A) Betöltöd ram-ba a fájlt egy tömbbe, List<string>-be, stb.
B) Készítesz hozzá egy tömbbe egy indexet, hogy hanyadik sor hanyadik byte-tól kezdődik. (Ha a TXT is irreálisan hatalmas, akár ezt is tárolhatod fájlban, sima bináris, int-ek/longok egymásután, abban egyszerű seekelni.)
C) Ha meg fix hosszúságú rekordokról van szó, ráadásul számokkal... Miért is .txt?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha annyira kurvanagy a txt, hogy szignifikáns a seek, akkor rosszul választottál storage-et.
Ha egy 3rd party progi köhögi ki, akkor lehet jobban jársz, ha előbb beolvasod List-be vagy valami bonyolultabb adatszerkezetbe, amit tudsz direktbe/gyorsan indexelni. Esetleg SQL-be átdolgozod.

Egyszerre válaszolnék a két kérdésre, azért txt mert az XCOM nevű program köhögi ki nekem elég sok különböző vegyületre és az így csinálja. Ebben vannak ugyan (tulnyomó részt) számok táblázat szerűen, de van benne sima szöveg is, ezért nem hatékony másként kezelni. Memóriába szerintem nem célszerű bevenni hosszú távra a dolgot, főleg mivel a tesztidőszak után akár hetekig elfutó szimulációról van szó, ahol másnak is lesz szüksége a véges memóriára.

--
MacBook Black
OS X 10.6.5

Mekkora txt fájlról van szó? Mi vele a feladat? Háthat tudunk jobb megoldást javasolni, mint az n. sor beolvasása.
Egyébként ha az n. sort keresed, akkor azt is lehet, hogy X byte-os blokkokban beolvasod, megkeresed a \r karaktert, ha találsz egyet, és van mögötte egy \n is, akkor növelsz egy változót, és leadminisztrálod, hogy globálisan hol találtad (összes beolvasott blokkhossz+aktuális blokkban az elválasztó indexe) (persze ha az sorelválasztó valami miatt csak \n, akkor elég azt számolni), majd (n-1)-nél mégegyszer eltárolod, és ha megtaláltad az n. \r\n-t is, akkor kiolvasod az n-1 és n közötti részt.

A txt pillanatnyilag nem olyan nagy, mert még csak tesztelek vele, de a végleges méretet nem tudom sajnos megmondani, attól függ hány különböző és mennyire komplex anyag kerül majd "szintillációs kristályként" a szimulációmba.

Egy viszonylag egyszerű Nátrium Jodid kristály esetén is már 80 fölött van a sorok száma, igaz ez még csak pár 10 kB adat, de reményeim szerint akár több ezer lényegesen bonyolultabb kristály és keverék fog végül szerepelni a programban, nőni fog az oszlopok száma is, bár az elhanyagolhatóan, viszont sorokban egy 2-4 millió közöttire számítok első körben.

--
MacBook Black
OS X 10.6.5

Egy olyan tömböt aminek minden eleme 10^-1 és 10^-10 közé esik és 8-10 értékes jegyet tartalmaz nem annyira triviális 30 megán eltárolni, de itt nem az a probléma, mert ezt még valahogy át is hidalnám és nem is lenne gáz az sem, ha 200 MB-ot fogyasztana el, csak mint már írtam ez egy olyan dolog ami igen ritkán kell, a többi dologhoz képes, viszont egy átlagos futás alatt olyan 1,5-2 millió alkalommal azért mégis keresek benne, ami a folytonos újrabeolvasást nem éri meg, de azt sem, hogy az egyébként produktív résztől akár csak 1% memóriát is elvegyen.
Egyébként, hogy az előző kérdést is megálaszoljam pillanatnyilag 3Gb memória áll a program rendelkezésére, élesben nem tudom még mennyit adok neki, egy 384 magos cluster 6 TB memóriáját fogja használni. De nem vagyok a memória pazarlás híve és nem utolsó sorban feltétlenül asztali gépeken is futtatható programot szeretnék írni, mert a célja az lenne a projektnek, hogy bármilyen sugárzást bármikor le tudjunk vele szimulálni, különösebb háttérismeret nélkül.

--
MacBook Black
OS X 10.6.5

Ember 6 TB ram mellett még csak véletlenül se akarj fájlból olvasni, ha nem muszáj. Fájlból, főleg szövegfájlból olvasni lassú, minden esetben. Magonként 16G ramod van, az rengeteg. (Nem inkább CPU az a "mag?" 16G ram/core nekem soknak tűnik összegben... Persze, van ahova megéri, csak...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Teljesen mindegy, hogy text vagy relációs tábla alapon kezeled, ha nem lesz mögötte elég sok RAM - előbbi esetben OS cache, utóbbiban DB bufferpool vagy OS cache - még index létezése esetén is meredek lesz feszt I/O-ra várni.

Az adott felállásban a kettő együtt volna az idális: akármilyen alapon index, ami folyamatosan a memóriában (is) van, ott frissül, és onnan szolgálja ki a tulajdonképpeni seeket.

Ha ugyanazon txt többszöri olvasásáról van szó (pl: mert hozzáírás van), akkor készíts hozzá (és tartsd karban) egy index fájlt, amiben benne van, hogy melyik indexeknél kezdődnek a sorok. Ezután gyorsan tudsz tetszőleges sorra ugrálni.

Ha valami struktúrált formában vannak az adatok, akkor az ADO textdrivere lesz a leggyorsabb. SQL segítségével ki tudod szedni a keresett sorokat, amit egyből egy DataTable-ben fogsz megkapni.

Ha C/C++ lenne a nyelv es linux a rendszer, akkor elso korben: mmap
Igy kezelheted mint egy egyszeru tombot. Aztan mindenkepp index epites a soremelesre. Kb 15-20 sornal nem tobb a program..

Azt nem tudom, hogy C#/Mono-val hogy lehet megoldani.