MFC: CFile

[domi (Gast)]

Hallo,

ich habe eine 60 MB Datei, die ich Byte für Byte durchsuchen muss. 
Momentan arbeite ich mit der Klasse CFile aus der MFC und lese jedes 
Byte einzeln mit Read() aus der Datei.
Ist ein großer Performancegewinn zu erwarten, wenn man die komplette 
Datei zunächst in einen Puffer läd und darauf arbeitet? Oder öfter 
größere Blöcke? Gibt es sonst Möglichkeiten das ganze zu beschleunigen? 
Sind die "alten" Datei-Zugriffsfunktionen z.B. fread schneller als die 
der Klasse CFile?

Gruß,
domi

[Blaubär (Gast)]

Derartig große Dateien kann man unter Win32 nur mit Memory Mapped-Files 
verwalten (CreateFileMapping etc.)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib/html/msdn_manamemo.asp

[Karl H. (kbuchegg)]

Um auf die ursprüngliche Frage zurückzukommen:
Nein, Performancegewinn ist keiner zu erwarten. So blöd
sind die Entwickler der I/O Libraries auch wieder nicht,
dass sie nicht selbst Buffer einbauen.

> Sind die "alten" Datei-Zugriffsfunktionen z.B. fread schneller
> als die der Klasse CFile?

CFile stützt sich letztendlich auf die selben Basisfunktionen
wir auch fread(). Da aber bei fread der ganze Klassenüberbau
wegfällt, ist das wahrscheinlich einen Tick schneller.

[Blaubär (Gast)]

60 MB mit fread oder CFile zu lösen macht nur leider überhaupt keinen 
Sinn, Herr Buchegger!!!

Sagt jedenfalls der Blaubär.

[Rufus Τ. F. (rufus)]

... der einfach keine Ahnung hat, so leid es mir tut.

Selbstverständlich kann man 60 MB mit fread (bzw. dem CFile-Wrapper) in 
den Speicher einlesen, sogar mit einem einzigen Aufruf, und dann lässt 
sich im Speicher nach den erforderlichen Daten suchen.  Man kann auch 
byteweise lesen (was die performance allerdings in der Tat erheblich 
senken dürfte), oder in 1 KB-Blöcken, oder wie auch immer.

Sicher, mit "memory mapped files" geht das auch, aber eben nicht 
nur. Was für ein Blödsinn.

Naja, kommt das "Blau" im "Blaubär" vom C2H5OH-Gehalt?

[Blaubär (Gast)]

@Rufus
Es wird auch nicht bestritten, daß man auch mit fread() 60 MByte auf 
einen Schlag einlesen kann. Aufgrund der desolaten Performance macht das 
aber überhaupt keinen Sinn (nur DAUs würden das machen), weshalb die 
Verwendung von Memory Mapped Files angebracht ist!!!

[domi (Gast)]

Danke für den Tipp, das ganze ist nun 30 mal schneller!

Gruß,
Domi

[Karl H. (kbuchegg)]

> 60 MB mit fread oder CFile zu lösen macht nur leider überhaupt
> keinen Sinn, Herr Buchegger!!!

Hab ich das gesagt?
domi hatte eine Frage zum Thema Performance Vergleich und
darauf bin ich eingegangen.

Erst mal lesen was wirklich da steht.

[Blaubär (Gast)]

> Danke für den Tipp, das ganze ist nun 30 mal schneller!

>Gruß,
>Domi

@Domi
Danke schön :-)

Gruß vom hilfsbereiten Blaubär (andere stänkern bloß rum!!)

[Mister M (Gast)]

Also:

Es macht natürlich Sinn, Dateien in "verdaulichen" Mengen einzulesen und 
nicht etwa Byte für Byte. Je nach Applikation, ist die Größe des zu 
benutzenden Puffers dann zu wählen (z. B. in 4 MB -Häppchen). Mit 
fileseek kann man sich die Datei scheibchenweise einlesen und auswerten. 
Wenn ein Durchlauf mehr als 1x pro Datei nötig ist, würde man die 
gesamte Datei (möglicherweise) einlesen.

Auf die Windows-Funktionen ala "Memory Mapping" würde ich mich nicht 
immer verlassen. In einigen Konstellationen kann das Betriebssystem u. 
U. lahmgelegt werden (z.B. bei Dateien, die Größer sind, als der zur 
Verfügung stehende Arbeitsspeicher). Dies ist regelmäßig unter WIN2k zu 
beobachten, leider aber auch unter WinXP. Entweder schreibt man einen 
eigenen File-Wrapper, der den Zugriff auf die Datei über einen eigenen 
(selber konfigurierbaren) Cache regelt, oder man bedient sich einer der 
zahlreichen Hilfsklassen, die wesentlich bequemer sind, als die 
MFC-Bordwerkzeuge. Ein Blick bei Codeguru bewirkt Wunder.