From: Webbiz on
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
"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
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
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
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!

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Fixing/ Rounding
Next: Last MSDN applicable to VB6