VB Speed Tip

Hello,

I am writing a game using DirectX and have a question about how to optimize speed.

Would the program run faster if:

Each object had its own raw vertex data and when drawing them their data is used. This would use lots or varibles but it loop would be tighter

E.g.

VB Code:

Private type gameObjects
V(3) as D3DTLVERTEX
X as single
Y as single
End Type
 
Dim Things(100) as gameObjects
 
Private Sub Form_load()
'Intialize all the game objects vertex data and store it in the objects
End Sub
 
Function DrawMe(what as integer)
Device.DrawPrimativeUP Things(i).V(0),2 
End Function

OR

Each object did not store its vertex data and a local varible in the drawing function stored the result of generated vertex data. This would use less varibles but the loop would slower.

E.g.

VB Code:

Private type gameObjects
X as single
Y as single
End Type
 
Dim Things(100) as gameObjects
 
Function DrawMe(what as integer)
Dim v(3) as D3DTLVERTEX
'Generate the vertex data and store it in V
Device.DrawPrimativeUP v(0),2 
End Function

I don't know anything about DirectX.
Just in general, Long is a lot faster than Integer. So, if possible, change "what" to long.

You can do the speed test yourself by using the GetTickCount API. See the CopyMemory example near the bottom of that page.

1) Why is DrawMe a function? It doesn't return anything. Setting a function up takes more time than setting a sub up.

2) Why are you passing DrawMe a parameter if you aren't using it? It takes time to pass parameters.

3) Inline code is always faster, but it's also larger. You have to trade speed and size.

Speaking of inlining, this alone:

VB Code:

Device.DrawPrimativeUP Things(i).V(0),2

is faster than this:

VB Code:

Function DrawMe(what as integer)
Device.DrawPrimativeUP Things(i).V(0),2 
End Function

And like iStank said (just kidding), Longs are always faster than Integers. Long is a 32 bit data type that works well with 32 bit processors. Integers (16 bit) have to be made into two to get to be 32 bit, go through a process to get the highs and lows, and process, hence why it's slower.

Moved.

Thanks for the replies, I usually use longs anyway.

Does inlining code really make a difference? I mean does size have a negative impact on speed?

And my major question would be "Does creating small local varibles in loops slow down loops and decrease performance or does creating excess varibles need the start of the program use up memory and slow down the program?"


PS: iPrank is a C# interface :lol:

In cases like you showed, inlining will make a huge difference to speed.. but then unless you can put the code into a loop, it will become very large if you add to it (such as "'Generate the vertex data").

The size of a sub/function does not affect speed.. only the readability/maintainability (it becomes easier to make mistakes/introduce bugs). If you can use a loop tho, this is not really an issue.


Having lots of variables can use up too much memory, which will slow things down.. but for that to happen you would have to have lots of large variables (an array of 250000 Singles uses less than 1MB!), or object variables which use a large amount of memory (how much they use depends on the objects).

As to creating variables in loops, it doesn't matter (in simple terms, the variable is actually created when the sub/function starts). What matters is the extra work you are doing with them... if you are aiming for speed, you should have everything you can outside of loops.


There is a good article about optimising code in our Classic VB FAQ's (link in my signature), which should help you to understand some of the things you could do to make your program faster.

Thanks, I will take a look at your link

Just for your information, GetTickCount is useless for speed profiling code, it only has a resolution of milliseconds. Use these functions:

Public Declare Function QueryPerformanceCounter Lib "kernel32" Alias "QueryPerformanceCounter" (lpPerformanceCount As LARGE_INTEGER) As Long

Public Declare Function QueryPerformanceFrequency Lib "kernel32" Alias "QueryPerformanceFrequency" (lpFrequency As LARGE_INTEGER) As Long

They reference hardware clocks will give resolutions of a 1000 times better, i.e. in microseconds. Also setting the priority of the process to 'Realtime' will inhibit windows from interfering with the timing, but do this with great caution, you won't be able to break out of an endless loop other than switching off the machine..! ;o)

Salvatore

Thanks, I will look into that, normally I use GetTickCount :blush: