Speeding up I/O

[Jhd.Honza]

Hi, I am trying to make a failure-tolerant (to I/O errors) file copy, using code like this:

for (long L = 0; L<sourceStream.Length; L++)
{
   try{sourceStream.Seek(L,SeekOrigin.Begin);}
   catch {//SEEK ERROR}

   try {destStream.Seek(L,SeekOrigin.Begin);}
   catch {//SEEK ERROR}

   int i;
   try {i = sourceStream.ReadByte();}
   catch {i = 0; //SOURCE READ ERROR}

   try {destStream.WriteByte(Convert.ToByte(i));}
   catch {//DEST WRITE ERROR}
}

But this is VERY slow process (~1MB/min), how could I speed it up?

[nemaroller]

Try-catch blocks obviously slow down your code...

But what mystifys me is what you are trying to accomplish.

A fault-tolerant file copy would redo any error it occured, but you seem to be doing it at every read of one single byte.

Why not put the entire read and write process in ONE try-catch...
if it fails, redo the whole process( or break up the transfer into blocks of bytes (10kb at a time).

You could also check the CanSeek property before starting a copy on the streams...

try{
for (long L = 0; L<sourceStream.Length; L++)
{
sourceStream.Seek(L,SeekOrigin.Begin);
destStream.Seek(L,SeekOrigin.Begin);
int i;
i = sourceStream.ReadByte();
i = 0;
destStream.WriteByte(Convert.ToByte(i));

}
}
catch
{}

[Pirate]

Originally posted by nemaroller
Try-catch blocks obviously slow down your code...

Only if the exception occured .

[nemaroller]

Yea.. I guess that wouldn't be the case here... unless he has a lot of errors....

or

Actually, now that you have me thinking about it, I wonder if the author is running this code in Debug mode.. because running through a try-catch in debug mode decreases performance significantly, even without errors.

[Jhd.Honza]

The aim is to finish copying even when error occurs. If you try to copy a file in explorer, using API or any other way, it fails with the first error and no data are available.

Lot of files however, e.g. text, bitmaps or videos are usable without some bytes. The errors I am going to get around are bad sectors probably the most time (disk failure, damaged floppy or scraped CD).

(I have possibility of 3 choices: omit unreadable byte, repeat previous one ore fill with predefined one (0 in case above)).

____________

nemaroller:
Trying to copy a file using conventional way at the first time is not needed, since mostly user would use this tool in case it fails. And, this try would be outside the snippet of code I wrote.

If try-catch blocks are so slow, I think the ones used while writing to the destination can be omitted, since I could assume the destination would be ok in most cases.
I also don't know whether the seek one is useful, I can manage it to work without Seek, just trust the ReadByte() is advancing the position by byte, or when error just to Seek +1 byte from current position. Would be this working in a block of unreadable bytes?

I was thinking to divide the process to copy half of bytes, if it fails then half of the half and so on - this will speed up the process until the first error, but take a lot of memory, won't it?

And last, yes, I'm running in debug mode.

[Pirate]

Originally posted by Jhd.Honza
The aim is to finish copying even when error occurs. If you try to copy a file in explorer, using API or any other way, it fails with the first error and no data are available.

Lot of files however, e.g. text, bitmaps or videos are usable without some bytes. The errors I am going to get around are bad sectors probably the most time (disk failure, damaged floppy or scraped CD).

(I have possibility of 3 choices: omit unreadable byte, repeat previous one ore fill with predefined one (0 in case above)).

Put your code into try-catch-finally block . the "finally" part always execute even if any error happens . So , you can put your finalizing code there .