🚀 go-pugleaf

On Thu, 15 May 2003 14:28:50 +0500, "Muhammad Momin Rashid"
<momin@hotmail.com> wrote:

>1. This approach is significantly slower than the windows file copy
>operation itself.  I need to speed up my file coping operation.

This operation should not be "significantly" slower, however, you must
certainly abandon TFileStream and use Win API (CreateFile, ReadFile,
WriteFile). You gain a little bit of power by bypassing the VCL layer,
but most importantly you are able to use the appropriate flags in
CreateFile such as - for example - the FILE_FLAG_SEQUENTIAL_SCAN flag
in dwFlagsAndAttributes.

The buffer size used in copying is critical. I use a size of 32K as
the best for all purposes.

>2. The operation consumes a lot of processing power while reading from media
>such as CDROM etc.  Is there any way to bring down the processor usage?

The only way is 1) to use a thread, and 2) to take a Sleep() for 0 or
1 ms, after each copyed chunk. This will give you a usage of about 4%
even on old hardware.

>3. If there is a problem in file reading (bad or corrupted media) the system
>locks up for a fair amount of time.  How to avoid this? and how can I
>control the amount of time system has to keep trying before it quits trying
>to read?

In most cases Windows recover. The behaviour varies between versions.
You can't do much about this except for using SetErrorMode with
SEM_FAILCRITICALERRORS especially in case of dealing with removable
media. In any case, the copy is handled by a thread which can send a
periodic signal to your main (UI) thread.


-- 

Nick B. Cassos