Difference between revisions of "Speed"

From HashVB
Jump to: navigation, search
 
Line 6: Line 6:
 
1. Buffering commonly used data
 
1. Buffering commonly used data
  
I am giving a simple example here.. Say you are building a hex-display. You know how to use the Hex$() function. However, if it's purpose is to display byte data you have the possibility of speeding up the process about 40%.
+
I am giving a simple example here.. Say you are building a hex-display. You know how to use the Hex$() function. However, if its purpose is to display byte data you have the possibility of speeding up the process about 40%.
  
 
  Public FHex(0 to 255) as String
 
  Public FHex(0 to 255) as String

Latest revision as of 14:52, 26 June 2006

float
 This article is based on Visual Basic 6. Find other Visual Basic 6 articles.

The first thing you need to clear out is Do I really need to speed up my code?. Think about the purpose of your application and the targeted end-user. Is he going to be satisfied with the speed you provide with your application? Would he benefit more if you provide more speed?

If the answer is yes, then consider:

1. Buffering commonly used data

I am giving a simple example here.. Say you are building a hex-display. You know how to use the Hex$() function. However, if its purpose is to display byte data you have the possibility of speeding up the process about 40%.

Public FHex(0 to 255) as String
Public Sub InitVariables()
Dim i as integer

For i = 0 to 255
    FHex(i)=Right$("00" & Hex$(i),2)
Next i

End Sub

Now you are able to use FHex(byte) instead of Hex$(byte) for 8bit numbers, which is faster with about 40%, and occupies about 1k in memory as a buffer and an instant to initialize at startup.

2. Move computations in user's acting time as much as possible.

What do I mean by that? Say you are building an Undo system for your application. Considering it's a user-interactive application (meaning that the user constantly inputs parameters to the application) you can use the instants in which the user acts to build your undo buffer.

Say, user pressed the "D" key (that triggers an operation), at that exact moment your application logs the change, updates the undo and why not, saves the changes to an autosave file. It's unlikely that the user will be able to move faster than the processing capabilities of the machine.

3. Use API calls as much possible, but responsibly.

The fun part with VB is that it allows you to use the high octane fuel called API. API's are functions built in with the operating system able to perform many operations at speeds much higher than one could program directly in VB. Please use the following references as guides to working with API's: Using Windows API in VB Tutorial MSDN API Guide Considering you had the patience and interest to read about the API's at least briefly, keep in mind that some API calls won't work on certain Windows versions. You need to check the compatibility of each API you use.

Bottom line: Do it only when needed, but DO sacrifice resources for speed! If you are a former assembly coder like I am, you might have principle issues with this statement. However, keep in mind the Earth is rotating and at this point there's nothing you or I can do about it. Most of the games coded in assembly now only work in special emulators thanks to some nostalgic fans. Otherwise, the word for it is obsolete. Keep up and exploit all the resources you can get your hands on. If you want to keep being productively creative you need to have the support to work with. Use the functions that the modern processors architecture provide. Use the large memory modern computers are equipped with. All the others are doing it.