[ NrmMyth @ 01.10.2005. 11:40 ] @
Pozdrav.

Imamo ovakav slucaj.
Code:
// pseudo
char tmp;
dok A ne dodje do EOF radi {
    A.read( &tmp, 1 );
    obradi tmp;
    B.write( &tmp, 1 );

// A i B su datoteke velike velicine, EG 1GB
}


Moze li tu MMIO ( memory mapped I/O ) ubrzati proces citanja i pisanja.

Ako ne moze, imate li koju drugu ideju.
[ X Files @ 01.10.2005. 15:41 ] @
Na ovo pitanje ti (laicki) odgovaram jer vidim da ti niko ne odgovara.

Da sam na tvom mestu, testirao bih sve mogucnosti koje su mi na raspolaganju,
i naravno, izabrao najbrzu.

Fajlovi velicine 1GB su svakako preveliki za smestanje u RAM, tako da ce (po mom
misljenju) usko grlo u celoj prici biti cesto pristupanje disku, sto je nadleznost
OS-a.

Mozda bi ucitavanje vecih buffer-a podataka, recimo 10-tak MB, i obrada celog
tog dela buffer-a u RAM-u bila brza nego ucitavanje/obrada bajt po bajt. Opet
kazem, ne znam - pokusaj.

Zbog cega potenciram ucitavanje vecih delova fajla u neki buffer:
Mala analogija sa listama.

Znam zasigurno da mnogi kontejneri (liste, itd), imaju properti Capacity, koji govori
koliko memorije da lista ODMAH zauzme. Dakle, lista za nekakav PRVI ->Add()
rezervise prostor za narednih recimo 12 dodavanja, pa kada dodje do
12-tog, onda rezervise prostor za sledecih 12 itd... To dalje znaci da memorija
postaje fragmetisana. A kada znam unapred da ce lista imati 10000 elemenata,
onda jednostavno postavis Capacity na 10000 i znas da naknadne interne
re-alokacije nema i time se podizu performanse.

Ovo sam i testirao kada sam prepakivao reci za neki recnik koji sam radio. Imao
sam 3 liste sa oko 400.000 elemenata.

Stvarno se ne razumem u funkcionisanje fajl sistema, ali cenim da mora biti jako
slicno...

P.S. Kod Borlanda, kada radim sa fajlovima koji staju u RAM, koristim klasu
TMemoryStream, a za tvoj slucaj koristim TFileStream... Imaju sve sto mi je
neophodno i pokazale su mi se najbrzim za takve operacije.

I na kraju, ALGORITAM ZA PROCESIRANJE ucitanih podataka moze biti najvazniji,
a njega nisi pomenuo.



[ NrmMyth @ 01.10.2005. 19:34 ] @
Algoritam je nezanemariv, a citanje i pisanje je kriticno.

Tko se razumije u MMIO? Jer sam negdje na forumu vec cuo za to, cak se malo i informirao, ali ne shvacam hoce li to uistinu donjeti ubrzanje gore navedenim procesima?
[ Mikky @ 01.10.2005. 22:32 ] @
Radi maksimiziranja performansi treba citati podatke iz fajla u koracima neke odredjene velicine, npr po 64kb. Citanje bajta po bajt je sporo jer se dosta vremena gubi kada OS pristupa fajlu svaki cas.
Takodje u Windows-u mozes da radis asinhrono citanje fajla, sto npr znaci da dok ti se iscitava sledecih 64kb iz fajla ti mozes da obradjujes onih prethodnih. Pogledaj u MSDN ReadFileEx(). Sto se tice memorijski mapiranih fajlova, iz mog iskustva sa Windows API-jem oni su nesto sporiji od sirovog pristupa sa CreateFile(), ReadFile() po 64kb, CloseFile(). Takodje nemoj da pokusavas da ucitavas ceo fajl od jednom jer ako je fajl prevelik to ti nece uspeti (ni u MMF ni u obicnom ReadFile() nacinju).
[ NrmMyth @ 01.10.2005. 23:17 ] @
Citat:
Mikky:Takodje nemoj da pokusavas da ucitavas ceo fajl od jednom jer ako je fajl prevelik to ti nece uspeti (ni u MMF ni u obicnom ReadFile() nacinju).

Svjestan sam toga.

Hvala ti Mikky, bio si vise nego informativan. :)

EDIT:
No jos nesto primjetio sam recenicu da OS stalno mora pristupati fajlu, zar to nece biti dosta brze kad se fajl otvara pomocu nekih open() funkcija.
Podpitanje: Sto to znaci otvoriti neku datoteku? Sto se kod otvaranja zapravo radi?

[Ovu poruku je menjao NrmMyth dana 02.10.2005. u 00:21 GMT+1]