Re: Speed Speed Speed - Cutting down on wasted cycles

On Tue, 23 Jun 2009 14:08:38 -0500, dpb <none@xxxxxxx> wrote:

Webbiz wrote:
...
A project I have that was originally written years ago but is
periodically modified has sections that are just too slow. This is the
result of my ignorance on how to best utilize VB6 coding techniques.
<snipperoni - a San Francisco treat>


General comments first--

1. The approach of not trying to optimize until its been shown there's
a need is admirable trait--until there is a problem try to write code
that is first legible and therefore more likely to be maintainable and
second, the most straightforward approach you can think of. When (and
more importantly _IF_) it's demonstrated there's a bottleneck,

Understood.

2. Find out _specifically_ by empirical timing precisely where the
bottleneck(s) are. More time by far has been wasted on shaving milli-
or microseconds off of portions of code that are thought to be the
problem areas but which actual profiling demonstrates aren't.

Agreed. I've narrowed down where my speed issues are to a routine that
contains both Recordset creation and extensive calculations within a
loop. So I had two sections within this one routine that were slowing
things down a lot.

I tacked first the Recordset issue first. Rather than create a
recordset that contained all the information the routine would need
for any situation, I change the SQL to deliver only the bare
essentials based on what the routine needed "at that time" only. This
saved significant time. Then I replaced some of the recordset
manipulation code to use an array instead (using .GetRows) that also
shaved off considerable waste.

Now I'm down to a loop that has to perform extensive date manipulation
mathematics, which brings me to the Weekday count component we're
currently dealing with.

So yes, your suggestion is indeed well taken.


So, those are both good starts.

3. Do _NOT_ confuse and equate efficiency in runtime w/ terseness of
source code; there is no necessary correlation at all to the length of
the source and the associated run time. (One of my favorite old timey
training aids in getting this across to new hires was the challenge to
write a long-running code in a very short amount of code. My answer to
the challenge was always

This is a valuable lesson. While I do like as least amount of lines in
my code as possible for clarity, I certainly don't want a bunch of
cryptic lines for the same reason, especially if there are no speed
gains.

10 GOTO 10

The point was rarely overlooked!! :)

4. When beginning to look for optimizations _ALWAYS_ start w/ the
algorithm/implementation of the solution, _NOT_ with simply tinkering w/
alternate instructions to do the same thing as already doing. Virtually
always, that recasting of the problem will be where the really
significant gains are.

Certainly makes sense. Unfortunately I cannot think up a different way
to perform the algorithm in question. This has left me to deal with
the alternate instruction approach, which has shown some improvement
over my bloated approach.

My inability to find an alternate approach to solving my particular
task aside, I understand what you are saying as being most important.


Finally, more directed to your immediate problem...

I didn't try to actually write a function, but my thought is that it
should be pretty simple to simply calculate the weeks elapsed and look
at the start day of the week of the initial date. Given there are a
fixed number of days/week, the number of weekend days is also fixed
depending on the relationship of the start day to an arbitrary
week-start day (Sunday/Monday/...). So, instead of the loop, simply
subtract the number of weeks*2 and make the adjustment for any partials
based on a lookup table and that start DOW.

This sounds interesting (and simple, though at this moment of replying
don't have it worked out).

I take my WholeWeeks and mulitply this by 2 to get weekend days.
Subtract this from my TotalDays.

Then I must make an adjustment based on what day of week the count
started and ended.

I've got to give this some thought, but it would seem to remove the
need for a loop. Thx. :-)


Lastly, one more general comment--the VB "Books Online" document has a
good section on programming style/techniques specifically for VB
addressing coding for performance from both memory and processing time.
I strongly recommend reading it from beginning to end and applying its
precepts; it's not particularly long but does have solid advice. And,
of course, there's the use of the compiler optimization flags to help
the compiler do the best it can given the limitations on the age of VB
and the design of the language itself. It actually doesn't do too
badly, however, if you give it the help outlined.

Is there a specific website that you refer to as "VB Books Online"?

Just one example of a minor detail--avoid Variants unless absolutely
there is a reason for using them. The add some extra overhead baggage
that there's no sense in paying for if you don't need the extra
facility, namely overloading data types. This function doesn't need
that. In general, that one falls in the realm of the second category of
optimization noted above, but there's no sense in ignoring
easy-to-include habits, either. The use of Long as indices in arrays
and For loops I noted in another response is another. It's just good
practice.

I was thinking about this as well, actually. When I noted the
"Variant" type, I was trying to remember why it was there. But then,
this is my old code and has been produced over the years as I was
learning one small thing after another.

Thank you VERY MUCH for taking the time to write your lesson.

Regards,

Webbiz


.

Relevant Pages

  • Re: DAO MUCH faster than ADO in this test
    ... DAO is well-known to be faster than ADO. ... Of course the DAO loop ran faster than the SQL loop; ... advantage of a table-type recordset, which only works on local tables. ... Dim starttime As Single, finishtime As Single ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do While Loop nested in another While causes error
    ... still doesn't explain why a nested DO loop would cause problems. ... Until you sort out the contents of the recordset, ... idHolder = rsGuestbook ... display that new ID. ...
    (microsoft.public.inetserver.asp.db)
  • Re: One more ! Calculating Recordset Values
    ... Well I am almost there lol, got the recordset to work properly returning all ... the values in the one "loop" so to speak and I can see them being returned ... >> Dim aTot, eTot, iTot, pSubTot, aStrengthSubTot, PTotal, SubTotal, ... >>> totals ...
    (microsoft.public.frontpage.programming)
  • Re: Iterating Functions
    ... previous iterations will be lost. ... Re-Read the table "ORDER BY" the sequence number ... indicates a loop!! ... nested Recordset objects but one Connection object with success. ...
    (microsoft.public.scripting.vbscript)
  • Re: One more ! Calculating Recordset Values
    ... EOF means that the end of the RecordSet has been reached. ... > 'Total = The sum of all the SubTotals ...
    (microsoft.public.frontpage.programming)
Loading