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 12:57 On Thu, 25 Feb 2010 09:13:56 -0800, mscir <mscir(a)yahoo.com> wrote: >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 --- Your idea and Horst's idea are pretty good and something I've never thought about. May not may not fix my particular problem, but if it increases speed overall, I'm for it. I'll have to give a lot of thought on what size to start off with, since it is quite difficult to know how large it can get. All depends on the amount of data the user loads into the program and how much data is resulted from it. But I like the simplicity and logic of what you both suggest. Thank you. Webbiz
From: Mike Williams on 25 Feb 2010 13:01 "mscir" <mscir(a)yahoo.com> wrote in message news:hm6b4l$kom$1(a)adenine.netfront.net... > 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? That's okay if you know for certain in advance what the absolute maximum required size is going to be, but if you don't know that information in advance then checking it as you add elements and Redimensioning by adding an extra fairly large number of elements each time it is about to run out is probably the best way, with the number you add being a fixed amount or a percentage of the current size or whatever, depending on what best suits your particular circumstances. You can then either leave the array at it last Dimensioned size or reduce it to the actual used size or whatever, again in accordance with what best suits the particular job you are doing. Mike
From: mscir on 25 Feb 2010 13:06 Webbiz wrote: > On Thu, 25 Feb 2010 09:13:56 -0800, mscir <mscir(a)yahoo.com> wrote: > >> 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 --- > > > Your idea and Horst's idea are pretty good and something I've never > thought about. May not may not fix my particular problem, but if it > increases speed overall, I'm for it. > > I'll have to give a lot of thought on what size to start off with, > since it is quite difficult to know how large it can get. All depends > on the amount of data the user loads into the program and how much > data is resulted from it. > > But I like the simplicity and logic of what you both suggest. > > Thank you. > > Webbiz 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 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Webbiz on 25 Feb 2010 15:07 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 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 00000003 2.98320103 [3608] 1208030 1208030 8 TestApp1 frmMain::ShiftLeftThree 00000004 2.98322463 [3608] 10974306 10974306 6 TestApp1 frmMain::SwingFilter 00000005 2.98324728 [3608] 1616396024 202076000 212 TestApp1 frmMain::DownBarCount 00000006 2.98327041 [3608] 1241288576 1241288576 2 TestApp1 frmMain::DateArraySort 00000007 2.98329306 [3608] 29312846 2720 1 TestApp1 frmRunItAll::Form_Load 00000008 2.98331547 [3608] 500881530 29301844 1 TestApp1 frmMetaView::LoadData 00000009 2.98333788 [3608] 599350 599350 349 TestApp1 frmMain::CheckTopValidity 00000010 2.98336124 [3608] -23553991326900 -23553991326900 1 TestApp1 frmMain::Report_Click 00000011 2.98339343 [3608] 22157674520 7723349744 1 TestApp1 frmMain::CalcDatesOne 00000012 2.98340797 [3608] 10745930482 10745930482 243196 TestApp1 frmMain::ForwardDate 00000013 2.98343134 [3608] 2539869898 2539869898 121866 TestApp1 Module1::GetTradingDays 00000014 2.98345351 [3608] 3360260 1982190 2 TestApp1 frmMain::GetPeaks 00000015 2.98347616 [3608] 11065406 11065406 3 TestApp1 Module1::FilterArray 00000016 2.98349881 [3608] 2659784118 2659784118 566025 TestApp1 MSFLUtil::FormatLDate 00000017 2.98352146 [3608] 2142010 2142010 2 TestApp1 frmMain::Form_Activate 00000018 2.98354363 [3608] 471576056 11060460 1 TestApp1 frmMetaView::PopulateSecurities 00000019 2.98356581 [3608] 29310126 29310126 1 TestApp1 frmRunItAll::FillGrid 00000020 2.98359013 [3608] 28923287560 37370008 1 TestApp1 frmMain::LocateSwings 00000021 2.98361230 [3608] 53123510 35220006 1 TestApp1 frmMetaView::mnuLoad_Click 00000022 2.98363614 [3608] 20791996 51270 3 TestApp1 frmMetaView::Form_Resize 00000023 2.98365879 [3608] 32956185466 3419698144 1 TestApp1 frmMain::cmdLoadData_Click 00000024 2.98368168 [3608] 17903504 17897774 1 TestApp1 frmMetaView::Form_Unload 00000025 2.98370385 [3608] 22960 22960 10 TestApp1 MSFLUtil::MSFL_ErrTest 00000026 2.98372698 [3608] 3661440640 3570054530 1 TestApp1 frmMain::CalcDatesTwo 00000027 2.98374987 [3608] 461900 461900 350 TestApp1 frmMain::CheckBtmValidity 00000028 2.98377204 [3608] 3274260 3274260 1 TestApp1 frmRunItAll::Form_Resize 00000029 2.98379564 [3608] 22040 22040 1 TestApp1 MSFLUtil::MakeLDate 00000030 2.98385453 [3608] 510318086 6350806 1 TestApp1 frmMetaView::Form_Load 00000031 2.98387766 [3608] 1384840 1384840 2 TestApp1 Module1::FilterDuplicates 00000032 2.98389935 [3608] 116610 116610 3 TestApp1 Module1::FormCount 00000033 2.98392153 [3608] 31699156 10764930 1 TestApp1 frmMain::FilterOne 00000034 2.98394394 [3608] 30204560 18236106 1 TestApp1 frmMain::TransferToDataArray 00000035 2.98396659 [3608] 20740726 20740726 3 TestApp1 frmMetaView::SizeControls 00000036 2.98398876 [3608] 1332454676 166591010 191 TestApp1 frmMain::UpBarCount 00000037 2.98401093 [3608] 996440 996440 1 TestApp1 frmMain::TurnOffOnTop 00000038 2.98403430 [3608] 460512696 428521276 1 TestApp1 frmMetaView::PopulatePriceRecs 00000039 2.98405695 [3608] 2987843736 8025220 1 TestApp1 frmMain::FilterTwo 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? It does seem to match what I see if so. Unfortunately, this application takes 'minutes', not seconds to run on a few of the machines here, one being the Windows 7 64bit and a couple being XP, one running over 2ghz and one just below 2ghz. Any clues? Thanks. Webbiz
From: Webbiz on 25 Feb 2010 16:24
On Thu, 25 Feb 2010 10:06:00 -0800, mscir <mscir(a)yahoo.com> wrote: >Webbiz wrote: >> On Thu, 25 Feb 2010 09:13:56 -0800, mscir <mscir(a)yahoo.com> wrote: >> >>> 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 --- >> >> >> Your idea and Horst's idea are pretty good and something I've never >> thought about. May not may not fix my particular problem, but if it >> increases speed overall, I'm for it. >> >> I'll have to give a lot of thought on what size to start off with, >> since it is quite difficult to know how large it can get. All depends >> on the amount of data the user loads into the program and how much >> data is resulted from it. >> >> But I like the simplicity and logic of what you both suggest. >> >> Thank you. >> >> Webbiz > >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 > >--- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- 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. I'm installing VB6 on the Win7 64bit machine to see if I can catch why it breaks with Error 9 on it and not on my Win7 32 bit design machine where it runs fast and well. Arrgh! |