file operations very slow
-
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.) The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg (true, // true for File Open, false for Save As "bdb", // Default file extension NULL, // Initial filename appearing in the edit box OFN\_HIDEREADONLY | OFN\_OVERWRITEPROMPT | OFN\_FILEMUSTEXIST | OFN\_PATHMUSTEXIST, szFilter, // Filters NULL); // Parent window // Set the default directory for file open. fdlg.m\_ofn.lpstrInitialDir = OutputDoc;And then:
if (fdlg.DoModal() == IDOK) { // file validity check snipped - just reads a header strcpy(BINFODB, fdlg.m\_ofn.lpstrFile); pApp->AddToRecentFileList(BINFODB); pApp->UpdateTitleBar(&(pApp->m\_pMainWnd->m\_hWnd)); }In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL). What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine. Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
-
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.) The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg (true, // true for File Open, false for Save As "bdb", // Default file extension NULL, // Initial filename appearing in the edit box OFN\_HIDEREADONLY | OFN\_OVERWRITEPROMPT | OFN\_FILEMUSTEXIST | OFN\_PATHMUSTEXIST, szFilter, // Filters NULL); // Parent window // Set the default directory for file open. fdlg.m\_ofn.lpstrInitialDir = OutputDoc;And then:
if (fdlg.DoModal() == IDOK) { // file validity check snipped - just reads a header strcpy(BINFODB, fdlg.m\_ofn.lpstrFile); pApp->AddToRecentFileList(BINFODB); pApp->UpdateTitleBar(&(pApp->m\_pMainWnd->m\_hWnd)); }In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL). What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine. Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
permutations wrote:
literally identical (I put the DOS code in a DLL).
This could be part of the problem; if the code is compiled for 16 bit and DOS, the emulation needed for it to work at all would slow it down. Plus depending on the implementation of said emulation, it may be artificially making it run slower to better mimic the original platform. You may want to consider porting the program to target Windows (32 bit at least).
-
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.) The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg (true, // true for File Open, false for Save As "bdb", // Default file extension NULL, // Initial filename appearing in the edit box OFN\_HIDEREADONLY | OFN\_OVERWRITEPROMPT | OFN\_FILEMUSTEXIST | OFN\_PATHMUSTEXIST, szFilter, // Filters NULL); // Parent window // Set the default directory for file open. fdlg.m\_ofn.lpstrInitialDir = OutputDoc;And then:
if (fdlg.DoModal() == IDOK) { // file validity check snipped - just reads a header strcpy(BINFODB, fdlg.m\_ofn.lpstrFile); pApp->AddToRecentFileList(BINFODB); pApp->UpdateTitleBar(&(pApp->m\_pMainWnd->m\_hWnd)); }In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL). What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine. Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
One crude technique I use sometimes is simply to break into the application periodically with a debugger and have a look at the call stack. Perhaps you'll get lucky and see the problem. A profiler would obviously be helpful and a lot more informative than my poor-man's profiler. Another classic is to simple scatter timing code throughout your code.
Steve
-
permutations wrote:
literally identical (I put the DOS code in a DLL).
This could be part of the problem; if the code is compiled for 16 bit and DOS, the emulation needed for it to work at all would slow it down. Plus depending on the implementation of said emulation, it may be artificially making it run slower to better mimic the original platform. You may want to consider porting the program to target Windows (32 bit at least).
It's compiled for 32-bit - sorry I didn't make that clear. The engine code was pulled from the original DOS program, and then recompiled for 32-bit Windows and packaged in a DLL. It's straight C code - should be efficient. Anyway, this isn't the part that is running slowly. It's the file open dialog, which is strictly on the interface side and has nothing to do with the original DOS code. To adapt the DOS program I separated out the interface and the engine, put the engine in a DLL, and wrote a Windows interface. It's the file open dialog in the Windows interface that is slow as molasses, and it's such a simple call. I don't get it. Just bringing up the file open dialog box takes a really long time.
-
One crude technique I use sometimes is simply to break into the application periodically with a debugger and have a look at the call stack. Perhaps you'll get lucky and see the problem. A profiler would obviously be helpful and a lot more informative than my poor-man's profiler. Another classic is to simple scatter timing code throughout your code.
Steve
Hmmm... That's a good thought. I don't have a lot of experience with profiling and looking for inefficiencies in code. I guess the call stack would tell me if weird things are being called that I didn't realize.
> Another classic is to simple scatter timing code throughout your code.
Could you explain more what you mean by timing code? You mean stick in traces that ... what would I trace - the entry and exit times in different functions?
-
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.) The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg (true, // true for File Open, false for Save As "bdb", // Default file extension NULL, // Initial filename appearing in the edit box OFN\_HIDEREADONLY | OFN\_OVERWRITEPROMPT | OFN\_FILEMUSTEXIST | OFN\_PATHMUSTEXIST, szFilter, // Filters NULL); // Parent window // Set the default directory for file open. fdlg.m\_ofn.lpstrInitialDir = OutputDoc;And then:
if (fdlg.DoModal() == IDOK) { // file validity check snipped - just reads a header strcpy(BINFODB, fdlg.m\_ofn.lpstrFile); pApp->AddToRecentFileList(BINFODB); pApp->UpdateTitleBar(&(pApp->m\_pMainWnd->m\_hWnd)); }In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL). What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine. Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
I think I may have a clue what's causing this... I'm developing the program with VS2008 on the Windows 7 machine, but I'm maintaining compatibility with VC++6 on an XP machine because I want to compile the release version there. This is a commercial program for home users, and my customers will mostly be running XP. I don't want to statically compile MFC, and I don't want to make them go get updated DLLs. On the XP machine, there is no delay in the file open dialog. It's just on the Windows 7 machine. I think this is because the common file dialog has been superceded on Vista and later: http://msdn.microsoft.com/en-us/library/ms646927(VS.85).aspx[^] I'll try switching to GetOpenFileName. If that's faster on Windows 7, then maybe I can use precompiler directives to use GetOpenFileName on Vista or later.
-
I think I may have a clue what's causing this... I'm developing the program with VS2008 on the Windows 7 machine, but I'm maintaining compatibility with VC++6 on an XP machine because I want to compile the release version there. This is a commercial program for home users, and my customers will mostly be running XP. I don't want to statically compile MFC, and I don't want to make them go get updated DLLs. On the XP machine, there is no delay in the file open dialog. It's just on the Windows 7 machine. I think this is because the common file dialog has been superceded on Vista and later: http://msdn.microsoft.com/en-us/library/ms646927(VS.85).aspx[^] I'll try switching to GetOpenFileName. If that's faster on Windows 7, then maybe I can use precompiler directives to use GetOpenFileName on Vista or later.
-
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.) The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg (true, // true for File Open, false for Save As "bdb", // Default file extension NULL, // Initial filename appearing in the edit box OFN\_HIDEREADONLY | OFN\_OVERWRITEPROMPT | OFN\_FILEMUSTEXIST | OFN\_PATHMUSTEXIST, szFilter, // Filters NULL); // Parent window // Set the default directory for file open. fdlg.m\_ofn.lpstrInitialDir = OutputDoc;And then:
if (fdlg.DoModal() == IDOK) { // file validity check snipped - just reads a header strcpy(BINFODB, fdlg.m\_ofn.lpstrFile); pApp->AddToRecentFileList(BINFODB); pApp->UpdateTitleBar(&(pApp->m\_pMainWnd->m\_hWnd)); }In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL). What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine. Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
Duhhhhhh... The problem wasn't my code at all. It was a setting on my Windows 7 system. I was displaying the folder list on the left for File Open dialogs. File Open was taking a long time in all my programs - (Word, etc). I changed this, and now it's speedy. I did try switching from CFileDialog to GetOpenFileName, but it made no difference.
-
Oh wow. I think this may be it. I did speed it up by getting rid of the folder list, but it's still not as fast as I'd think it should be. Thanks for this!