🚀 go-pugleaf

If you are reading, examining and possibly altering the file's data prior to
writing a new file then what you are doing is not a copy and a comparison to
the speed to that of Windows' CopyFile operation is not valid.

If I had that task and were concerned about speed, I would apportion most of
my efforts to two items:

-I would use the native API for the file operations
-I would try to optimize my activities with respect
 to data examination and alteration.

I would probably use CreateFile, ReadFile, WriteFile and CloseHandle and
specificly open with FILE_FLAG_NO_BUFFERING and allocate aligned data
buffers to facilitate that mode.

I would probably use one of several different functions for examining and
altering a given file and its data depending upon which variation of
alteration is desired for a given file and what file size is to be handled.

If many files were to be handled, it may be profitable to investigate
apportioning the files among various threads and investigate the utility of
requesting a higher priority from Windows.

Note that without careful programming, no changes, including none of what I
have said, are likely to provide significant benefit.  You must try code,
evaluate its performance and compare to alternate versions of the code.
Typically you will find that the bulk of any differences in speed reside in
20% or less (probably much less) of the code but without evaluation and
performance comparisons you will end up spending time to optimize portions
where the effects of the optimization are trivial.  For instance, it could
turn out that performance using TFileStream is within 2% of that using
other, lower level methods, because the bulk of the time is spent elsewhere.

.  Ed

> Muhammad Momin Rashid wrote in message
> news:3ec3be2e@newsgroups.borland.com...
>
> I am not using CopyFile function because I need to have
> control over the data being copied, in some cases I need
> to clean the corrupted data (which occurs due to faulty
> media).  This the reason I am reading file in chunks
> and writing these chunks to a new file.
>
> Given the above scenario, can you think of an alternate i can
> use, which is both speedier and gives me this sort of control?