CODEWITHSUNDEEP
c#windows-servicescrc32
Vikineese
Vikineese

Reputation: 61

Reading files from Mapped network drive is quite slow when compared to USB in C#

I'm copying files from USB and network mapped share drive to my Server. Before copying files I 'm doing certain validations and once the validation is okay then I'm copying the files to the destination. Significant validation is CRC validation using the System.Interop.Services. All this is done by a Windows Service written in C#.

Problem : Both my USB and Mapped network drive modules go through the same code i.e. code that does the CRC validation and copy.

From USB if i start my process with a 800MB file then the CRC validation takes maximum 30 secs and copying in maximum 1 minute.

From Network Mapped Drive if i start my process with a 800MB file then the CRC validation takes around 10 minutes and copying in maximum 1 minute.

  1. Why is this difference ?
  2. Why the same operation from USB is much faster than the Network mapped drive ?
  3. Is it just because of the Ethernet speed ? or something else technically ?

If it is with the speed then for me to copy the file it takes only 1 minute in both USB as well as Mapped Network Drive. Only while performing the CRC (again same code & logic for both USB & NT mapped drive) I'm observing this difference.

Addition Info : I have used .Net Framework, C#, wNetAddConnection for mapping network drive.

Request your expert opinion on the same.

Code for CRC Validation :

internal class CRC 
{ 

[System.Runtime.InteropServices.DllImport( "CRC.dll" )] 
public static extern int Validate665Loadset( string pszLoadsetPath );

}

This is what i'm calling and it returns the value. If it is ZERO then content is valid else not. Thats the logic.

Upvotes: 3

Views: 1146

Answers (1)

Marc Gravell
Marc Gravell

Reputation: 1063013

How are you accessing the file? Yes, it is entirely possible that there are simply very different bandwidths, but CRC validation taking 10 times as long as copying for the same origin (network) suggests the code is doing something funky - since both basically involve reading all the bytes, they should be about the same (caveat: the OS can optimize the copy scenario in some cases - for example copying a single file over multiple NICs at the same time - which won't be possible if using the file as a stream). I suspect the first thing to look at is the buffer size; or possibly adding an explicit BufferedStream.

Upvotes: 1

Related Questions