• Welcome to Valhalla Legends Archive.
 

Speeding Up Visual Basic

Started by CupHead, October 19, 2003, 09:05 AM

Previous topic - Next topic

CupHead

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:


Dim MyString as String
Dim i as Long

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

MsgBox "Finished."


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:


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] = '.';


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.

Adron

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


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


Or in C:


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;
}


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

drivehappy

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.

Eibro

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

Grok

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

Zakath

Quote from: Grok on October 19, 2003, 02:40 PM
CupHead, that's a useful post for people who stubbornly use a hammer as a screwdriver.

Wait...you mean Tim the Tool Man was LYING? I always wondered why the hammerhead didn't really fit the screw...
Quote from: iago on February 02, 2005, 03:07 PM
Yes, you can't have everybody...contributing to the main source repository.  That would be stupid and create chaos.

Opensource projects...would be dumb.

Adron

Quote from: Zakath on October 19, 2003, 02:50 PM
Quote from: Grok on October 19, 2003, 02:40 PM
CupHead, that's a useful post for people who stubbornly use a hammer as a screwdriver.

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

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.

K

#7
Quote from: drivehappy on October 19, 2003, 11:25 AM
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.

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

Grok

Quote from: K on October 19, 2003, 05:52 PM
The idea is that you use a 32bit type on a 32bit processor, although I'm sure the performance gain from this is negligible.

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.

Banana fanna fo fanna

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

TheMinistered

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.

Etheran

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

iago

Even numbers can also be bad, but it depends on the word size of the CPU.
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*