There are many authors on this throughout the years, but still most of us (including myself), don't obey the rules for speed ;)

However, the binding issue is a big one, for example:

1) There is almost never a reason to do the following:
DIM x as NEW MyObject
x.property = value

Instead:
DIM x as MyObject ' no NEW keyword
Set x = new MyObject
x.property = value

The reason is that in the first example, VB must check to see if the object has been created, create it if necessary, then process the property value,
every time you access a property or method, it has this extra internal code wrapped around it saying 'does this object already exist?'
If you replace it with the 2nd example, VB knows the object was created and does not generate the internal 'wrapping' code.

The only reason why you would want to use the first example is if you are only going to use one method or property of an object, then destroy it, or the object may never get instantiated in the application, say for a word mail merge.

Also, try to avoid passing parameters As Object, instead pass it as As 'myobject'; The as Object also generates extra code to validate the object
being passed, if you tell VB the exact object type, then the compiler hard codes the reference in the EXE (in your case you may not be able to
do this)

2) As far as static memory, asking the OS for memory is a slow operation for any language. consider the following:
DIM x as string
x = "1234"
x = "12345"
x = "123456"

Each of those calls requires VB to possibly ask the OS for more memory. However:
DIM x as string * 50
x = "1234"
x = "12345"
x = "123456"

VB allocates a fixed 50 bytes, then fills it from left to right, no asking for more. Of course now if your app needs more than 50, you will have
to find a way on the fly to store the extra.

VB statically allocates memory for at least the following:
Static Memory:
DIM x as integer, boolean, & other numeric types
DIM x as STRING * fixed limit

Dynamic Memory:
Variants used on the fly without declaring
DIM x as STRING (no length specifier; VB doesn't know how big it will get)

Dynamic memory comes from a 'pool' in VB, and every so often, VB searches through the pool for dead variables and packs the
pool, the bigger you have made the pool, the longer it takes VB to go through it. A little tiny pool is the way to go!

OK, I have to get some real work done now ;)





>Ed, for early binding. I have recently changed from dim myObj as object to dim myObj in some areas to allow me the opportunity to use a different year specific control in my app. Could you talk more about the benefits of using this throughout. Also, how can I use static memory in the app? This topic interests me a great deal, hoping that others would too. I made a new thread.
>
>... snip snip ...
>* Origionaly From the inheritance thread.
>* Ed Vanduyne said:
>>In fact, for true VB speed (rivaling C applications), you have to follow a few simple rules:
>>
>>1) Early bind all objects, never use 'As Object'; allowing the VB/C compiler to hard link entry points.
>>2) Use static memory throughout the application (if possible), VB's memory manager still runs garbage collection, the less garbage, the
>>faster your program.
>>3) Avoid using collections, and other inefficient storage mediums. Use arrays or API memory copy routines if possible.
>>4) - ... {your input here!}
>>
>>I've used these practices in detailed real-world examples, with the greatest of success.
>
>... more snip snip ...