patterncMinor
Copying directories in Windows 10
Viewed 0 times
copyingwindowsdirectories
Problem
I wrote a program to copy directories in Windows 10. I have tested copying a directory (696MB) in 3 different ways:
What can I do to improve the performance of my program to be as fast as xcopy?
```
#include
#include
#include
#include
#include
int copyfile(const char inputfile, const char outputfile);
void CopyDirectory(const char src_dir, const char dst_dir);
int main(void)
{
clock_t t1 = clock();
// src directory must end with \\*
/ dst directory must end with \\ /
CopyDirectory("C:\\Users\\green\\Downloads\\Folder1\\*",
"C:\\users\\green\\desktop\\Folder1\\");
clock_t t2 = clock();
printf("time elapsed : %.4f secs\n", (double)(t2 - t1) / CLOCKS_PER_SEC);
puts("Press any key to continue...");
getchar();
return 0;
}
void CopyDirectory(const char src_dir, const char dst_dir)
{
intptr_t hFile;
struct _finddata_t c_file;
char *ptr;
char buf[MAX_PATH + 20];
char tmp_dir[MAX_PATH + 20];
char f_name[MAX_PATH + 20];
strcpy(buf, src_dir);
ptr = buf + strlen(buf) - 1;
if ((hFile = _findfirst(src_dir, &c_file)) == -1L) {
fprintf(stderr, "Failed to open directory %s\n", src_dir);
return;
}
CreateDirectoryA(dst_dir, NULL);
while (_findnext(hFile, &c_file) == 0) {
if (c_file.attrib & _A_SUBDIR) {
if (strcmp(c_file.name, "..")) {
/....../
strcpy(tmp_dir, dst_dir);
strcat(tmp_dir, c_file.name);
strcat(tmp_dir, "\\");
/....../
*ptr = '\0';
strcat(buf, c_file.name);
strcat(buf, "\\*");
CopyDirectory(buf, tmp_dir);
}
}
else {
strcpy(tmp_dir, dst_dir);
strcat(tmp_dir, c_file.name);
*ptr = '\0';
st
- xcopy: time taken - 52 seconds
- ctrl+c: time taken - 78 seconds
- My program: time taken - 193 seconds
What can I do to improve the performance of my program to be as fast as xcopy?
```
#include
#include
#include
#include
#include
int copyfile(const char inputfile, const char outputfile);
void CopyDirectory(const char src_dir, const char dst_dir);
int main(void)
{
clock_t t1 = clock();
// src directory must end with \\*
/ dst directory must end with \\ /
CopyDirectory("C:\\Users\\green\\Downloads\\Folder1\\*",
"C:\\users\\green\\desktop\\Folder1\\");
clock_t t2 = clock();
printf("time elapsed : %.4f secs\n", (double)(t2 - t1) / CLOCKS_PER_SEC);
puts("Press any key to continue...");
getchar();
return 0;
}
void CopyDirectory(const char src_dir, const char dst_dir)
{
intptr_t hFile;
struct _finddata_t c_file;
char *ptr;
char buf[MAX_PATH + 20];
char tmp_dir[MAX_PATH + 20];
char f_name[MAX_PATH + 20];
strcpy(buf, src_dir);
ptr = buf + strlen(buf) - 1;
if ((hFile = _findfirst(src_dir, &c_file)) == -1L) {
fprintf(stderr, "Failed to open directory %s\n", src_dir);
return;
}
CreateDirectoryA(dst_dir, NULL);
while (_findnext(hFile, &c_file) == 0) {
if (c_file.attrib & _A_SUBDIR) {
if (strcmp(c_file.name, "..")) {
/....../
strcpy(tmp_dir, dst_dir);
strcat(tmp_dir, c_file.name);
strcat(tmp_dir, "\\");
/....../
*ptr = '\0';
strcat(buf, c_file.name);
strcat(buf, "\\*");
CopyDirectory(buf, tmp_dir);
}
}
else {
strcpy(tmp_dir, dst_dir);
strcat(tmp_dir, c_file.name);
*ptr = '\0';
st
Solution
Re-architect to do lots of reading, then lots of writing - then loop.
OP's code presently reads file A, writes file A, reads file B, writes file B, ...
Reading file A, file B,.... partial file Z and then writing those into a large
I first noticed this huge saving BITD when
A central issue, that unless you get deeper into the DISK I/O, code is limited to trying to do what it thinks the file system wants best in order to perform fast.
Using multiple threads (one for reading, one for writing) may help too.
OP's code presently reads file A, writes file A, reads file B, writes file B, ...
Reading file A, file B,.... partial file Z and then writing those into a large
buffer is certainly faster. Of course it is more complicated as code needs to pick-up where it left off in the middle of file Z.I first noticed this huge saving BITD when
XCOPY . came out as it read many files first versus the old COPY .. This paradigm has been consistently true with my subsequent coding experiences.A central issue, that unless you get deeper into the DISK I/O, code is limited to trying to do what it thinks the file system wants best in order to perform fast.
Using multiple threads (one for reading, one for writing) may help too.
Context
StackExchange Code Review Q#140289, answer score: 2
Revisions (0)
No revisions yet.