STUMPED! VB6 app on Win7 64 system
in [Visual Basic]
|
Prev: Fixing/ Rounding
Next: Last MSDN applicable to VB6
From: Nobody on 25 Feb 2010 22:31 "Webbiz" <nospam(a)noway.com> wrote in message news:i0kdo558vt19silaumgtvo2n5flb9fto4v(a)4ax.com... > On Thu, 25 Feb 2010 03:16:57 -0500, "Nobody" <nobody(a)nobody.com> > wrote: >>Another option is the following free profiler software. The difference is >>that it shows timing information to the nearest microsecond or so, while >>the >>above method uses the system clock, which is accurate to about 10 to 20 ms >>or so. By default, DebugView doesn't show millisecond resolution, so you >>need to use Options-->Show Milliseconds to show them. >> >>Visual Basic Profiler >>http://www.holmea.demon.co.uk/Profiler/Install.htm#EXE >> > > I downloaded the Profiler and read the instructions. I did the same > with Dbgview.exe. Placed a couple of buttons on my app and created a > .LOG file from the results. > > The section dealing with my application called here "TestApp1" is > below. I have searched the internet for instructions on how to > interpret what this is. I've been unable to do so. > > 00000002 2.98315430 [3608] 1808580 1808580 9 TestApp1 > frmMain::ShiftLeftOne > In the screenshot of the Profiler output(Which has DBWin32 in the title), ignore the first column "348:". This is the process ID, the second and third columns are timing information in CPU clock count. I don't know what the 4th column represent, which is a small number usually shown with a value less than 10. What you are using is DebugView, not DBWin32. DebugView shows a sequence number, followed by elapsed time in seconds since the first call to OutputDebugString. To show the time in clock time format, see the Options menu. > Can someone here tell me what these columns represent? > > I know the first one is the line number and the second is suppose to > be TIME. > > On the TIME, what scale is this? The program ran from > > 2.98315430 to 2.98405695 > > The difference is .0009026. > > So say 9026. Milliseconds? Would this mean 9 seconds? No, it's 0.0009026 Seconds, or 0.9026 Millisecond, but this is not the speed of execution of your program, but the speed at which the profiler printed its report. The profiler prints its report using OutputDebugString(), and DebugView doesn't care who is calling OutputDebugString(), it just shows you when OutputDebugString was called. To interpret the result, go to the 4th and 5th columns in DebugView. The 3rd column is the process ID. You need to divide the 4th and 5th columns by the speed of the CPU in Hz to get the result in seconds. It's best to export the results to Excel, and add extra columns to show the speed in seconds.
From: Webbiz on 26 Feb 2010 00:19 On Thu, 25 Feb 2010 22:31:16 -0500, "Nobody" <nobody(a)nobody.com> wrote: >"Webbiz" <nospam(a)noway.com> wrote in message >news:i0kdo558vt19silaumgtvo2n5flb9fto4v(a)4ax.com... >> On Thu, 25 Feb 2010 03:16:57 -0500, "Nobody" <nobody(a)nobody.com> >> wrote: >>>Another option is the following free profiler software. The difference is >>>that it shows timing information to the nearest microsecond or so, while >>>the >>>above method uses the system clock, which is accurate to about 10 to 20 ms >>>or so. By default, DebugView doesn't show millisecond resolution, so you >>>need to use Options-->Show Milliseconds to show them. >>> >>>Visual Basic Profiler >>>http://www.holmea.demon.co.uk/Profiler/Install.htm#EXE >>> >> >> I downloaded the Profiler and read the instructions. I did the same >> with Dbgview.exe. Placed a couple of buttons on my app and created a >> .LOG file from the results. >> >> The section dealing with my application called here "TestApp1" is >> below. I have searched the internet for instructions on how to >> interpret what this is. I've been unable to do so. >> >> 00000002 2.98315430 [3608] 1808580 1808580 9 TestApp1 >> frmMain::ShiftLeftOne >> > >In the screenshot of the Profiler output(Which has DBWin32 in the title), >ignore the first column "348:". This is the process ID, the second and third >columns are timing information in CPU clock count. I don't know what the 4th >column represent, which is a small number usually shown with a value less >than 10. > >What you are using is DebugView, not DBWin32. DebugView shows a sequence >number, followed by elapsed time in seconds since the first call to >OutputDebugString. To show the time in clock time format, see the Options >menu. > >> Can someone here tell me what these columns represent? >> >> I know the first one is the line number and the second is suppose to >> be TIME. >> >> On the TIME, what scale is this? The program ran from >> >> 2.98315430 to 2.98405695 >> >> The difference is .0009026. >> >> So say 9026. Milliseconds? Would this mean 9 seconds? > >No, it's 0.0009026 Seconds, or 0.9026 Millisecond, but this is not the speed >of execution of your program, but the speed at which the profiler printed >its report. The profiler prints its report using OutputDebugString(), and >DebugView doesn't care who is calling OutputDebugString(), it just shows you >when OutputDebugString was called. > >To interpret the result, go to the 4th and 5th columns in DebugView. The 3rd >column is the process ID. You need to divide the 4th and 5th columns by the >speed of the CPU in Hz to get the result in seconds. It's best to export the >results to Excel, and add extra columns to show the speed in seconds. > Thanks Nobody. Would it be too much to ask the designer of that program to build in the functionality rather than having us copy stuff to Excel? LOL! :-) Webbiz
From: Webbiz on 26 Feb 2010 01:16 Well, the problem seemed to be external to the program as it acted differently even on the same OS on different computers. I was able to track down exactly what the problem is. The reason the program was slowing down so much on some machines and not on others is that the program is designed to only load in 10 years worth of data. However, installing VB6 on the machine that the program was running slowly on, the Windows 7 64bit system, and tracing through the program, I found that it was loading ALL THE DATA given it. This was really causing the program to bog down in those loops. The reason it was loading ALL THE DATA is because of a 3rd party function I use that converts a "Short Date" into a format of YYYYMMDD would exit out early if the "Short Date" format did not use two digits for both DD and MM. My Windows 7 64bit system is set with m/d/yyyy and not mm/dd/yyyy (I'm in the US). The culprit can be seen right here: ====================================== Public Function MakeLDate&(strDate As String) 'On Error GoTo MakeLDate_Err ' Make sure we got at least the minimum allowable length string passed If (Len(strDate) < 8) Then GoTo MakeLDate_Err ' Make a copy of the string so we don't destroy the original Dim strBuf As String strBuf = strDate Dim strTmp As String ' For temporary extraction Dim lMonth As Long Dim lDay As Long Dim lYear As Long 'MM ' Extract the first two chars from the buffer - should be the month strTmp = Left(strBuf, 2) ' Eat the first 2 chars off the buffer strBuf = Right(strBuf, Len(strBuf) - 2) ' See if we pulled a dash (month came out as a single digit) and eat it if we did If (InStr(1, strTmp, "-") > 0) Then strTmp = Left(strTmp, 1) Else ' The dash is in the buffer - eat it strBuf = Right(strBuf, Len(strBuf) - 1) End If ' Validate that we extracted a number If (Not IsNumeric(strTmp)) Then GoTo MakeLDate_Err ' Store the month lMonth = CLng(strTmp) ' Validate month If (lMonth < 1 Or lMonth > 12) Then GoTo MakeLDate_Err ' Add the month to the date (YYYY[MM]DD) MakeLDate = lMonth * 100 'DD ' Extract the next two chars from the buffer - should be the day strTmp = Left(strBuf, 2) ' Eat the first 2 chars off the buffer strBuf = Right(strBuf, Len(strBuf) - 2) ' See if we pulled a dash (day came out as a single digit) and eat it if we did If (InStr(1, strTmp, "-") > 0) Then strTmp = Left(strTmp, 1) Else ' The dash is in the buffer - eat it strBuf = Right(strBuf, Len(strBuf) - 1) End If ' Validate that we extracted a number If (Not IsNumeric(strTmp)) Then GoTo MakeLDate_Err ' Store the day lDay = CLng(strTmp) ' Validate month If (lDay < 1 Or lDay > 31) Then GoTo MakeLDate_Err ' Add the day to the date (YYYYMM[DD]) MakeLDate = MakeLDate + lDay 'YYYY ' The remainder of the string in the buffer is the year. ' Validate that we have a number If (Not IsNumeric(strBuf)) Then GoTo MakeLDate_Err ' Store the year lYear = CLng(strBuf) ' Validate the year If (lYear < 1900 Or lYear > 2999) Then GoTo MakeLDate_Err ' Add the year to the date ([YYYY]MMDD) MakeLDate = MakeLDate + lYear * 10000 ' Done Exit Function MakeLDate_Err: MakeLDate = -1 End Function ==================================== Notice that this routine expects the first two chars to represent the month. Well, what if it is only one char? Or even worse, what if the first two char represents the DD and not MM? Well, the solution to this problem is to make sure that strDate represents mm/dd/yyyy no matter what. Would you say that this will do the trick? strDate = Format(strDate, "mm/dd/yyyy") Then feed strDate into MakeLDate? Hmmm. Yep! Works like a charm. Case closed. Webbiz
From: mscir on 26 Feb 2010 16:08 <snip> >> What does the code do on a slow machine if you comment out the Redim line: >> >> If DateValue(ResultDate) > DateValue(sLastDataDate) - 7 then >> If DateValue(ResultDate) < DateValue(sLastDataDate) + 60 Then >> 'store results >> 'ReDim Preserve AllDates(AD_Count) >> AllDates(AD_Count) = ResultDate >> AD_Count = AD_Count + 1 >> End If >> End If > No change in speed on Win 7 64bit machine. > However, the code now fails at the Redim where the array is resized to > what it should be once all the data is loaded into it. Error 9. Apologies, I forgot to comment out the line that increments AD_Count too. You could run it that way to see if it makes any difference, if you're interested in fine tuning it. Mike --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: kpg on 26 Feb 2010 16:15
Are X and Y declared as Integers? |