I have a Win32 command line application that uses ODBC calls to access any database. Everything seems to be working great, except for a minor performance issue that we are now battling. At the end of the code, as the application is termination, we are seeing a "pause" that can run as long as 2.5 seconds (or more).
This is not in my code, but rather is AFTER my code exits. The end of the application looks like this:
if(DisplayTimes)
PrintTime("Tearing Down SQL Environment");
TearDownSQLEnvironment();
if(DisplayTimes)
PrintTime("Complete!");
exit(ReturnStatus);
}
When run, I get a list of timestamps including the following:
18:29:43.650: Finished Data Read
18:29:43.650: Free Statement Handle
18:29:43.650: Disconnect from Database
18:29:43.728: Tearing Down SQL Environment
18:29:43.728: Complete!
As you can see, the call to disconnect from the database takes some time, but tearing down the environment takes almost no time at all. The problem, though, is that the program is exiting, but control is not returned to the command line for some time thereafter. The code snippet shows a Process Monitor trace that shows that the Thread Exit call is occurring at 18:29:43.719 (actually a bit BEFORE the program actually finishes, but this could be a timer issue). In any event, nothing happens for the next 2.5 seconds and we sit there waiting for the command prompt to come back. Even checking through the intervening calls with ProcMon, I don't see anything other than the typical "idle chatter" of AV and other agents. (No, AV is not the issue, as I can duplicate the problem on other systems with no AV code.)
The application I am using is called SQLExec, and is also available for download from www.goldstarsoftware.com/tools.asp. You can test it yourself to any ODBC database by issuing a command like this:
SQLEXEC <DSNName> "SELECT TOP 1 * FROM TableName" /DT
The app is fast, but the delay FOLLOWING the app is positively maddening! Help!
I've surmised that this is unloading of DLL's related to ODBC and the database, but I have not found a way to confirm this as of yet.
17145 18:29:43.7198046 sqlexec.exe 4640 Thread Exit SUCCESS User Time: 0.0000000, Kernel Time: 0.0000000
19361 18:29:46.2529335 sqlexec.exe 4640 RegOpenKey HKLM\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize SUCCESS Desired Access: Read
19362 18:29:46.2529836 sqlexec.exe 4640 RegQueryValue HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles NAME NOT FOUND Length: 20
19363 18:29:46.2530469 sqlexec.exe 4640 RegCloseKey HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize SUCCESS
19365 18:29:46.2531342 sqlexec.exe 4640 Thread Exit SUCCESS User Time: 0.0312500, Kernel Time: 0.2031250
19374 18:29:46.2542871 sqlexec.exe 4640 Process Exit SUCCESS Exit Status: 0, User Time: 0.0468750, Kernel Time: 0.1562500
19375 18:29:46.2545963 sqlexec.exe 4640 CloseFile C:\Develop\Win32\SQLExec\Release SUCCESS
19377 18:29:46.2548343 sqlexec.exe 4640 CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03 SUCCESS
1:
2:
3:
4:
5:
6:
7:
8:
Select allOpen in new window
by: Infinity08Posted on 2008-05-10 at 01:17:51ID: 21538206
Since you suspect that the delay is caused by the exit call, it's worthwhile to investigate everything that exit does :
1) the functions registered with atexit are executed (do you have any ?)
http://www.cplusplus.com/r
On Windows, also check functions registered with _onexit
http://msdn.microsoft.com/
2) the streams are closed after flushing their buffers (do you have any open streams, especially file streams ?)
3) temporary files are deleted (does your code use any temporary files ?)
4) control is returned to the host environment
Make sure to not only check your code, but also the libraries you are using, etc.