VB Forum / General / December 2004

I wonder about this too. I read something once about smaller variables being
less efficient, because their size gets increased so that they "align" in
memory with the larger ones.

?

If you are really into performance then first, you must obtain a copy of
Matt Currland's book "Advance Visual Basic 6". Also read Bruce McKinney's
"Hardcore Visual Basic" which is included on the MSDN Library/Help CD.
[Sidenote: M$ includes the Ver 2 book, but the sample code is for vb5 - you
can download the updated code at:
http://brucem.mystarband.net/mckinney2a.htm

The most important aspect of learning how to generate better performance is
profiling and testing your code. As an application becomes more complex it
is often not possible to predict actual behavior within YOUR problem domain.
Both of the above books not show methods of optimizing code, but ways to
measure their effect as well.

I would also recommend checking out the vbAccelerator site:
http://www.vbaccelerator.com
(Also the various vb mvp's sites)

Functions and Subs -
Yes, for some return types there is additional code created for providing a
return that presents an "over-head" if it is not used. In other situations
it is essentially a none issue - again you have to test to make sure.

Part of the difficulty with this type of "thought-tuning" is that compiling
a VB application is a multiple step process. One of these steps, if
compiling to native code, is the optimizer. Often rather lengthy, wasteful
appearing code is optimized down to something rather slick (the opposite can
happen just as easily <g>). In some cases compiling to "pcode" will result
in a faster operation than native code. Again you have to test.

Integers and Longs -
In most languages an 'integer' is the common integral type for the the
platform. eg, in Win32 it is 32-bit. In VB6 an Integer is a 16-bit creature,
a Long is 32-bit. In general, operations are faster in Win32 using a VB Long
and not a VB Integer. But again, in practice, you will have to test it as
you can run into another of VB's little idiosyncrasies: VB's hidden type
coercion. VB might in some cases convert longs to integers and vice versa.

Often little difference is actually noted in practice by this apparently
obvious performance issue.

Static Variables -
A static variable is simply a 'global' variable that can only be seen in the
scope of the routine it is defined in. An auto variable is one that is setup
on the stack when a function is called. So yes you can save a few clicks
when a routine is called repeatedly. The trade-off is your code image
becomes larger. Also if the 'static variable' is used like an auto and has
to be set to some intial value each time the routine is called - you have
lost some of the clicks you thought you were saving.

It is also possible that you might limit the optimizer from creating its
best output by using this technique opposed to using stack variables.
Again - you have to test and see.

With...End With -
Because of VB's 'interpreted' roots and its 'COM' model when using objects
(a horrible generalization <g>), using With...End With is always a good
idea. But it is only useful when a particular multi-level reference is
'referenced' more than one time. eg, your second example is essentially what
the With...End With construct does.

Again try it and see with your components in your problem domain.

Dictionary Object -
The dictionary object is one of the few cases where something in the FSO can
actually be faster than VB6's inherent Collection. But using anything from
the FSO is potentially a problem and VB's Collection class is poorly
written.

There are various alternative "collection" classes available on the net. Use
one of them.

Whew! hth

-ralph