🚀 go-pugleaf

"Andrue Cope" <not.a.valid@email.address.sorry> wrote in message
news:VA.00001cc9.007db8e9@email.address.sorry...
> Muhammad Momin Rashid,
>
> > 1. This approach is significantly slower than the windows file copy
> > operation itself.  I need to speed up my file coping operation.
>
> Is this for a compressed file? The Windows shell copies those without
> decompressing them first.

No, this is a normal file copy operation, which attempts to read chunks of
data from a file and write it to another file without modification unless
there is a media error.

> > 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?
>
> I wouldn't have thought so but what size buffer are you using? You should
use
> at least 16kB but less than 64kB. Also check if the CDROM reader is using
PIO
> or DMA. Windows tends to use PIO if it's at all unsure about the CDROM
> reader's ability.

I am using a 512K buffer at the moment, let me try reducing the buffer size
and see if it results in any significat speed improvement.  My devices are
set to use DMA, so theoratically such copying operation should not use CPU
Cycles at all.

> > 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
>
> Check your buffer. If you are reading too much in one go it might have
this
> effect.

Are you sure about this?  I thought when you try to read a part of a file
and error occurs, the read function just quits and returns the number of
bytes read.  Whereas, your response gives an impression that even if an
error occurs the read function continues to read (byte by byte or in some
preset chunks?) until it reaches the desired number of bytes to read.  Maybe
I need a bit more elaboration on this issue.

Thanks for your time and help
Regards,
Muhammad Momin Rashid.

> Andrue Cope
> [Bicester, UK]
>