As many of you know, Visual Basic does not provide for the fastest execution of code, particularly with respect to strings. We can illustrate this with appending 50000 characters to a string in VB:

[code]
Dim MyString as String
Dim i as Long

For i = 1 To 50000
MyString = MyString & "."
Next i

MsgBox "Finished."
[/code]

This code will take a significant amount of time to run because each time it loops, VB re-allocates the array in order to have sufficient space for each character. This means suffering through the VB function call, going through the VB runtime, going through whatever system calls, and finally, executing the machine code for the "translated" function. However, if we execute the same code another way:

[code]
Dim MyString as String
Dim i as Long

MyString = Space(50000)

For i = 1 To 50000
Mid(MyString, i, 1) = "."
Next i

MsgBox "Finished."

'This code basically amounts to the C++ equivalent of MyString[Index] = '.';
[/code]

it executes much, much, much more quickly. Obviously, these are hardly practical applications, however, it's an illustration of how pre-allocating your strings will speed up your code immensely (and without the need for writing assembly inside of Visual Basic *cough* TheMinistered *cough*). Doing simple optimizations like this (in your DataArrival event, for instance) will prevent the string from having to be continually resized and spare the overhead involved in that.

This doesn't just apply to Visual Basic. You can write equally bad code in C++:

[code]
std::string MyString;
for(int i = 0; i < 50000; i++)
MyString = MyString + ".";
[/code]

Or in C:

[code]
char *q, *p = malloc(1);
int i;
p[0] = 0;
for(i = 0; i < 50000; i++) {
q = malloc(i + 2);
strcpy(q, p);
strcat(q, ".");
free(p);
p = q;
}
[/code]

I think the flaw is a bit more obvious in C though...

Also I've heard for reasons I can't explain (but it has been tested) that if you declare variables as Long instead of Integer, statement involving the variables will execute twice as fast - but it involves more memory.

Some STL containers also suffer from this deficiency, see reserve() and resize() member functions to avoid unnesessary reallocations.

CupHead, that's a useful post for people who stubbornly use a hammer as a screwdriver.

[quote author=Grok link=board=5;threadid=3144;start=0#msg24620 date=1066592417]
CupHead, that's a useful post for people who stubbornly use a hammer as a screwdriver.
[/quote]

Wait...you mean Tim the Tool Man was LYING? I always wondered why the hammerhead didn't really fit the screw...

[quote author=Zakath link=board=5;threadid=3144;start=0#msg24622 date=1066593051]
[quote author=Grok link=board=5;threadid=3144;start=0#msg24620 date=1066592417]
CupHead, that's a useful post for people who stubbornly use a hammer as a screwdriver.
[/quote]

Wait...you mean Tim the Tool Man was LYING? I always wondered why the hammerhead didn't really fit the screw...
[/quote]

Some hammers' backs are I-shaped and can be used as screwdrivers for large screws if you really want to. You get good leverage too.

[quote author=drivehappy link=board=5;threadid=3144;start=0#msg24602 date=1066580749]
Also I've heard for reasons I can't explain (but it has been tested) that if you declare variables as Long instead of Integer, statement involving the variables will execute twice as fast - but it involves more memory.
[/quote]

The idea is that you use a 32bit type on a 32bit processor, although I'm sure the performance gain from this is negligible.

[quote author=K link=board=5;threadid=3144;start=0#msg24654 date=1066603927]
The idea is that you use a 32bit type on a 32bit processor, although I'm sure the performance gain from this is negligible.
[/quote]

I'm sure that has nothing to do with performance in your own Visual Basic code. None of your code will ever meet the CPU directly.

It does help performance a bit. A 32 bit number is a 32 bit number.

DriveHappy, it shouldn't increase or decrease speed. Parameters, in visual basic, are either passed by a *(ByVal) or **(ByRef). I don't see the effects of using a long vs integer.

never have a variable stored at an odd offset! I can't stress this enough, although I think this applies more towards assembly programmers because I think todays compilers adjust that for you (maybe even the most recent assemblers do too). ;D

Even numbers can also be bad, but it depends on the word size of the CPU.