CODEWITHSUNDEEP
c#
schmoopy
schmoopy

Reputation: 6649

Is there a faster way to copy a file other than File.Copy

It takes about 2 minutes to do a File.Copy(src, dest); for a 1.6GB File from Folder A to Folder B on the same drive. Is there a faster way to do this in C#/.NET in code (w/o hardware) - Something with stream, threading etc?

Would a filestream be quicker? How about a class that chunks up the file using a threadpool, and reads a range of bytes/writes a range of bytes [that sounds like a great way to corrupt the file, but integrity is not priority 1 here, its speed :-)]

I have searched but everyone says use File.Copy, but it's slow (as slow as Windows Copy) - I would prefer not to use a 3rd party tool.

Here are some answers to some of the questions:

Copy time comparison:

> C# : 2.15m  
> Windows Explorer: 2.53m  
> TeraCopy: 2.26m
> FastCopy: 2.24m

Ok, those are not averages and I know they may change slightly on subsequent runs, but I really thought there would be a faster way to copy a file since I assumed that Windows was doing additional security and integrity checks :-(

I'm still hoping for some good answer (like 'oh yea, files over 1.5GB will be x faster if you do buffer m and turn off security n') -- ok, I'm just wishing at this point.

Upvotes: 19

Views: 17059

Answers (8)

alpha_one_x86
alpha_one_x86

Reputation: 50

All will depends of the allocation decided by the OS at the moment of copy, if the file is in cache (do 5x in same way to avoid it).

The most clear result is if your repeat the test multiple times.

Upvotes: 0

Zuljin
Zuljin

Reputation: 2640

I think that you should firstly check how much your disk is fragmented. If your file is in many pieces and you don't have large continuous free space for second one then disk must move head much often which is very slow.

Maybe your disk is simple old and slow and you reach it's maximum performance. In that case solution is simple you need to buy new one, or better two and create RAID 0.

You may also check if during copying something else doesn't use the same disk, for example anti-virus or indexing service.

I didn't propose any software solution, because I don't believe there is anything faster than functions provided by OS.

Upvotes: 0

STW
STW

Reputation: 46366

For a single file, going to/from the same drive, the answer to your question is: no.

For network transfers, moving tons of files, and other more complex scenarios there may be room for improvement.

If your current requirement is to copy GBs to a second physical (non-symbollic) location on the same disk, then your best chance for improving performance is probably a faster disk.

Upvotes: 1

Mark Ransom
Mark Ransom

Reputation: 308206

I haven't tried this, but it might be fast.

Do two memory mappings, one to the input file and one to the output, and move memory from one to the other. The page mapping performed by the OS is tuned to the highest possible performance, since it impacts the overall system speed.

Upvotes: 2

Conrad Frix
Conrad Frix

Reputation: 52645

File.Copy does a call to CreateFile in Kernel32.dll. If you were copying lots and lots of tiny files (think millions) it might be worthwhile to do the P/Invoke to play with the parameters and skip the Permission Demands. One big file 99.999% of the 2 mins is spent inside the driver code.

Upvotes: 5

Brian Gideon
Brian Gideon

Reputation: 48949

If you are interested in creating a symbolic or hardlink instead of an actual copy then the following Windows APIs might be helpful.

Upvotes: 8

Guffa
Guffa

Reputation: 700342

You could try to use the hardware already at your disposal, and allocate a large buffer in memory. By reading and writing in larger chunks you might be able to remove some of the overhead.

However, there isn't much overhead to get rid of, the bottle neck is still the disk I/O. I would expect at best something like a 5% reduction in execution time.

Upvotes: 5

rerun
rerun

Reputation: 25505

I would assume that windows copy, file.copy, Copyfile All use the same underlying operating system calls to do copying. I would doubt that anything you write would outperform the OS internal calls.

Upvotes: 2

Related Questions