STUMPED! VB6 app on Win7 64 system
in [Visual Basic]
|
Prev: Fixing/ Rounding
Next: Last MSDN applicable to VB6
From: Webbiz on 25 Feb 2010 02:49 I have a small application that installs just fine on XP, Vista and Win 7 32 & 64 bit. The program even runs on all of these as well. The problem? On my Windows 7 64-bit laptop that is a 2.1ghz Dual-Core with 4g memory, this application runs so slow it makes you think it locked up. ------------------- Well, I placed a few 'caption' lines in the code to try and determine where this bottleneck was occurring. This is an example of that code segment that Win7 64 drags on. For X = 0 To HighDatesCount - 2 For Y = X + 1 To HighDatesCount - 1 'get days minus weekends TradingDays = GetTradingDays(HighDates(X), HighDates(Y)) 'calculate ratios If TradingDays > 4 Then RatioResult = TradingDays * .404 'store result in a variable ResultDate = ForwardDate(HighDates(Y), RatioResult) If DateValue(ResultDate) > DateValue(sLastDataDate) - 7 And 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 Next Y Next X So you know, HighDatesCount = 365. So it isn't a whopping large value. This code does not affect my Win7 32 bit machine, nor my XP machines. Just the 64 bit Win 7 machine. Anyone have an idea as to why this code would run at a snail's pace on my Win7 64 machine? What is the solution? Thanks. Webbiz
From: Nobody on 25 Feb 2010 03:16 "Webbiz" <nospam(a)noway.com> wrote in message news:p7aco5duhoto664kkr3bsjpga14e12s1m7(a)4ax.com... >I have a small application that installs just fine on XP, Vista and > Win 7 32 & 64 bit. > > The program even runs on all of these as well. > > The problem? > > On my Windows 7 64-bit laptop that is a 2.1ghz Dual-Core with 4g > memory, this application runs so slow it makes you think it locked up. > > ------------------- > > Well, I placed a few 'caption' lines in the code to try and determine > where this bottleneck was occurring. This is an example of that code > segment that Win7 64 drags on. > > For X = 0 To HighDatesCount - 2 > For Y = X + 1 To HighDatesCount - 1 > > 'get days minus weekends > TradingDays = GetTradingDays(HighDates(X), HighDates(Y)) > > 'calculate ratios > > If TradingDays > 4 Then > RatioResult = TradingDays * .404 > > 'store result in a variable > ResultDate = ForwardDate(HighDates(Y), RatioResult) > > If DateValue(ResultDate) > DateValue(sLastDataDate) - > 7 And 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 > > Next Y > Next X > > > So you know, HighDatesCount = 365. So it isn't a whopping large value. > > This code does not affect my Win7 32 bit machine, nor my XP machines. > Just the 64 bit Win 7 machine. > > Anyone have an idea as to why this code would run at a snail's pace on > my Win7 64 machine? There maybe other factors, such as different data, rather than OS type. Try using OutputDebugString() before and after each function call, and before and after ReDim. Use DebugView to view the result, which includes timing information so you don't have to add timing code to your application. To view OutputDebugString output, use this free software, which doesn't require installation: DebugView: http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx Declaration: Public Declare Sub OutputDebugString Lib "kernel32" Alias _ "OutputDebugStringA" (ByVal lpOutputString As String) Usage: OutputDebugString "ABC" Or: DebugPrint "ABC" Wrapper sub: Public Sub DebugPrint(ByRef s As String) Debug.Print s OutputDebugString s & vbCrLf End Sub 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
From: Horst Heinrich Dittgens on 25 Feb 2010 09:12 Are you sure that your functions don't waste the time? If yes, I would redim blockwise, f.e. by doubling the dim size each time the nescessary size exceeds Dim size, and maintain a dim size variable, and if your app later on uses UBound() then simply downsize to proper dim value after loop has ended. Redim always allocates a new memory block and copies the old into the new one, which is in a loop far more work than doing only a few redims and resizing at the end.
From: mscir on 25 Feb 2010 12:13 Horst Heinrich Dittgens wrote: > Are you sure that your functions don't waste the time? > > If yes, I would redim blockwise, f.e. by doubling the dim size each time > the nescessary size exceeds Dim size, and maintain a dim size variable, > and if your app later on uses UBound() then simply downsize to proper > dim value after loop has ended. > > Redim always allocates a new memory block and copies the old into the > new one, which is in a loop far more work than doing only a few redims > and resizing at the end. What about making the array as large as it might ever be before the loops, updating an array counter inside the loops, then redimensioning the array after the loops are finished, so there is only one redim performed? --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Webbiz on 25 Feb 2010 12:54
On Thu, 25 Feb 2010 03:16:57 -0500, "Nobody" <nobody(a)nobody.com> wrote: >"Webbiz" <nospam(a)noway.com> wrote in message >news:p7aco5duhoto664kkr3bsjpga14e12s1m7(a)4ax.com... >>I have a small application that installs just fine on XP, Vista and >> Win 7 32 & 64 bit. >> >> The program even runs on all of these as well. >> >> The problem? >> >> On my Windows 7 64-bit laptop that is a 2.1ghz Dual-Core with 4g >> memory, this application runs so slow it makes you think it locked up. >> >> ------------------- >> >> Well, I placed a few 'caption' lines in the code to try and determine >> where this bottleneck was occurring. This is an example of that code >> segment that Win7 64 drags on. >> >> For X = 0 To HighDatesCount - 2 >> For Y = X + 1 To HighDatesCount - 1 >> >> 'get days minus weekends >> TradingDays = GetTradingDays(HighDates(X), HighDates(Y)) >> >> 'calculate ratios >> >> If TradingDays > 4 Then >> RatioResult = TradingDays * .404 >> >> 'store result in a variable >> ResultDate = ForwardDate(HighDates(Y), RatioResult) >> >> If DateValue(ResultDate) > DateValue(sLastDataDate) - >> 7 And 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 >> >> Next Y >> Next X >> >> >> So you know, HighDatesCount = 365. So it isn't a whopping large value. >> >> This code does not affect my Win7 32 bit machine, nor my XP machines. >> Just the 64 bit Win 7 machine. >> >> Anyone have an idea as to why this code would run at a snail's pace on >> my Win7 64 machine? > >There maybe other factors, such as different data, rather than OS type. Try >using OutputDebugString() before and after each function call, and before >and after ReDim. Use DebugView to view the result, which includes timing >information so you don't have to add timing code to your application. > >To view OutputDebugString output, use this free software, which doesn't >require installation: > >DebugView: >http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx > >Declaration: > >Public Declare Sub OutputDebugString Lib "kernel32" Alias _ > "OutputDebugStringA" (ByVal lpOutputString As String) > >Usage: > >OutputDebugString "ABC" > >Or: > >DebugPrint "ABC" > >Wrapper sub: > >Public Sub DebugPrint(ByRef s As String) > Debug.Print s > OutputDebugString s & vbCrLf >End Sub > > >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'll check this out. Thanks!! Webbiz |