News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

File Copying

Started by ecube, September 19, 2009, 07:17:30 AM

Previous topic - Next topic

ecube

I was curious would trying to copy a file by read/writing multiple parts in threads be faster than just a CopyFile? or is windows copying the max speed alrready(think my max speed is 60 megabytes a second for writing, no sure) and there's no point?

hutch--

Cube,

I have this sneaking suspicion that the limitation will be the disk, while an OS can multi-thread, a hard disk cannot and it would have to thrash the read head to two or more locations which may slow it down. If you were reading data from disk, processing it and writing it back to disk there are apportunities to seperate disk reads and writes from processing overheads which will reduce your total time with the task but I doubt that direct disk copy will benefit from multithreading.

I would not be afraid to give it a blast though, you may get some priority gain by running more threads. try it on two threads first, open the file for read, work out a tile size then read that much at a time in the first thread while trying to do the same thing in the second. Clock a single thread versus two threads and see if its faster, slower or much the same.

There is another factor that may limit any speed gains, the system controls file cache usage and does what is called "lazy writes" after the data has been written to cache memory so you may have to try flushing the file system after each write.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

BlackVortex

Writes aren't done in real-time, they're cached, so the fastest thing to do is to just do the operation normally and let windows work its magic. I believe multithreading it will totally throw off the cache strategy and it will take a long time for all the threaded writes to complete.

I'd expect hard disk operation and cache strategy to be optimized for normal/forward reading and writing.

BATSoftware

Unless your planning to bypass Windows and do physical disk I/O, multithreading is bad idea. Optimizing disk access strategies is not childs play. Given the very complete disk driver caching on both hardware and O/S i would stick to sequential I/O using WINAPI routines in a single thread. There will be no gain using multi-threaded or async I/O for a basically sequential operation.