Jim;
I have developed many programs that do intensive use of file access and
I have ever used Blockread and blockwrite. This are for reading any
file type inlcuding .exe, DAT etc. I have a encryption program and we
process files of 600MB and more.
This are very fast routines, reading and writing blocks of 8KB or 64 KB
or even 1MB are really fast.
In my personal FTP server I have written a very simple routine to do
cached writes and in the moment of heavy work-load with many
simultaneous writes to different files, this routine do the thing in a
more efficient way than using blockwrite or write alone.
Regards
Jim Burns escribió:
>Hi all,
>
>Just a request for thoughts here. I'm at a decision point and I'd like some
>fresh thoughts on file access methods. Specifically, using standard file
>I/O methods be it CreateFile/ReadFile/WriteFile in the Win32 API directly,
>or in the guise of a TFileStream, as compared to Memory-Mapped files.
>
>I've used them all so I'm looking for subtle distinctions here. But once I
>make my decision I need to move forward so I'd just like to cover the bases.
>
>
>I guess the biggest point I'm struggling with is that someone I've read in
>the past suggested they liked Memory mapped files because they could use
>existing memory related functions rather than file handles. Not sure I see
>this as a significant point.
>
>One point that's been made in the past is not needing to handle the file I/O
>with memory mapped files, not having to manually handle file buffering. But
>then again managing the mapped view window across the file itself isn't much
>different than managing a file buffer in my mind.
>
>Richter ("Advanced Windows, 3rd ed.") points out that with memory mapped
>files one can access huge files, mapping say an 18EB file into a 32-bit
>address space. But TFileStream is (at D7) at least smart enough to use
>Int64's for such things to that despite being a signed value leaves
>something like 9,223,372,036,849,999,999 on the positive side. 32-bit
>Windows itself may still be using 32-bits for such things but even so
>functions like SetFilePointer provide a low and high value for effectively
>doubling the function's reach. So where's Richter's real advantage for
>memory mapped files here?
>
>Ignoring such things as sharing across process boundaries, data commitment,
>coherence of multiple views, memory files with out physical storage, and
>other advanced concepts, speaking just in terms of file access, file I/O, be
>it convenience, performance, or whatever, can anyone make a case for
>memory-mapped files over other methods?
>
>
>TIA,
>
>Jim
>
>
>------------------------------------------------------------------------
> Jim Burns, <mailto:[EMAIL PROTECTED]>
> Technology Dynamics
> Pearland, Texas USA
> 281 485-0410 / 281 813-6939
>
>__________________________________________________
>Delphi-Talk mailing list -> [email protected]
>http://www.elists.org/mailman/listinfo/delphi-talk
>
>
>
---
avast! Antivirus: Saliente mensaje limpio.
Base de datos de Virus (VPS): 0610-1, 08/03/2006
Comprobado en: 09/03/2006 11:45:57 p.m.
avast! tiene los derechos reservados (c) 2000-2004 ALWIL Software.
http://www.avast.com
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
