speed?

[nareth]

i was rading an article about optimizing speed

i was just wondering is
Dim A As Long

A = 1&

faster than

Dim A As Long

A = 1

[Jacob Roman]

I believe it is faster. But I think it may make sence to use & next to a variable rather than a number. What I mean by this is this right here:

Dim A As Long, B as Long

B& = 1
A& = B&

Simply saying A = 1 since variables represent memory locations to store data just shows that you are storing the value 1 into the memory location of A. Values themselves don't really have a data type. But Variables on the other hand do to represent the type of data to store and allocate a number of bytes for that memory location depending on what data type you declared it as. Like 2 Bytes for Integer variables and 4 Bytes for Long variables has been allocated for that memory location.

Now A = B on the other hand, you are saying that you want the memory location's data to be copied into A. Putting the & (Long data type symbol) next to all the variables that are declared as long will let the compiler know what data types they are and prevent conversions from one data type to another. In my opinion, A& = B& will be saying that B's 4 byte long integer register's data will be copied into A's 4 byte long integer register. Saying A = B on the other hand will be saying B's unknown register's data will be copied into A's unknown register. And extra assembly code will be added to convert them to their proper data types, thus slowing things down.




I'm know assembly guru or anything like that, but I believe they can answer that better than I can.

[nareth]

oh ok thank you, i was thinking something like that.

[Merri]

I made a test with these two codes:

    For X = 1 To ITERATIONS
        A& = 1&
    Next X

    For X = 1 To ITERATIONS
        A = 1
    Next X

There was no speed difference at all. Compiled, all advanced optimizations turned on, ten million iterations and ran many times.

[nareth]

can you post a img of the options?

[Merri]

In my opinion, A& = B& will be saying that B's 4 byte long integer register's data will be copied into A's 4 byte long integer register. Saying A = B on the other hand will be saying B's unknown register's data will be copied into A's unknown register. And extra assembly code will be added to convert them to their proper data types, thus slowing things down.

If you are using Option Explicit and have declared A As Long and B As Long, no data type conversion will be done. Compiler is smart enough to optimize that.

[nareth]

can you post a img of the options?

?????

[nareth]

also another question..

If UCase$(Account.Name) <> UCase$(Param(1)) Then
strcomp(UCase$(Account.Name),UCase$(Param(1)),vbTextCompare)
If UCase(Account.Name) <> UCase(Param(1)) Then
strcomp(UCase(Account.Name),UCase(Param(1)))

wich is faster?

[Merri]

can you post a img of the options?

I don't understand what you mean with that.


The one with $ is faster. In this case, UCase$ is string based, while UCase is variant based. There will be data type conversion when there is no $.

Then... as for the optimization, you have lots and lots to improve there.

strcomp(UCase$(Account.Name),UCase$(Param(1)),vbTextCompare)

If you are doing UCase$(), you don't need to do text compare, because of UCase$. You could actually take UCase$() out and just have text compare, because it is faster than calling UCase$() two times.


Then about the fastest comparison you can get:

'first check the length of the string (LenB is faster than Len)
If LenB(Account.Name) = LenB(Param(1)) Then
    'then check if we can find it
    If InStr(1, Account.Name, Param(1), vbTextCompare) = 1 Then
        'it is a match
    End If
End If

[nareth]

that helps alot merri thank you

[nareth]

i also red that mid$ is faster than let

so: Let DBHost = GetPrivateProfileString(Main.Name, "DBHost", DBHost, App.Path & "\settings.ini")

is slower than: Let Mid$(DBHost, 1) = GetPrivateProfileString(Main.Name, "DBHost", DBHost, App.Path & "\settings.ini")

?

[Merri]

Looks like I really should write the benchmarking article

[nareth]

what do you mean with benchmarking...

if its about let . just stfu and leave me with let i like it. otherwise sorry

[Jacob Roman]

I made a test with these two codes:

For X = 1 To ITERATIONS
A& = 1&
Next X

For X = 1 To ITERATIONS
A = 1
Next X

There was no speed difference at all. Compiled, all advanced optimizations turned on, ten million iterations and ran many times.

Merri, I already said that values have no data type, but variables do. Doing 1& will not make a difference at all. And why did you use a for loop? That's not the way to find out which is faster. Have you seen my performance test using the GetQueueStatus API in my faster DoEvents methods located in the code bank?

[nareth]

is a do while loop faster than a for loop?

[Jacob Roman]

Well yeah. But if DoEvents is in there, a major performance it will result because DoEvents is slow. There are faster methods. But both kinds of loops are ok anyways because one is infinite and the other one is not. For Loops and Do Loops are two different things and used for different operations. Like you can't use a For loop for a game loop or a rendering loop.

[nareth]

could you give me the link of the custom doevents .. thanks lot

[Jacob Roman]

I edited my post above yours. I forgot some things to add. Here's the URL though:

http://www.vbforums.com/showthread.php?t=315416

[nareth]

... so

Do While I < J
I = I + 1
Loop

is faster than

For I = 0 To J
Next

[dis1411]

here is the answer:

A = 1&

tells the compiler to store 1 as a long, otherwise it would have been stored as an integer. it saves a type conversion.


edit: oh, and the for next is faster than the do while

[Merri]

Jacob: because I used sTime class module (available somewhere from the first contest thread) which gives very accurate results on how many ms a code ran. I see no problem running the code a lot of times to see if there is a difference.

You also ignored my comment on the fact compiler is wise enough to detect defined variables and thus prevent datatype conversion when it is not required (you said A& = B& would have difference to A = B, which isn't true and I also tested this).


dis: depends on usage. On raw benchmarking Do loop is faster. I've sometimes encountered situatations when For loop worked faster, but I can't recall when it was. I'm not sure about it either, memory always gets muddy over time.

Also... I noticed no difference between 1 and 1&, so I believe compiler did notice this situatation and optimize it to be a long instead of an integer.

[Jacob Roman]

I did read your thing, Merri, when you said that the compiler is wise enough to detect defined variables. But you ignored what I said when values don't have a data type, variables do. Which is why you will not see a difference in 1 and 1&.

I'm going to do an experiment with A = B and A& = B& with my performance test...

[nareth]

depends on usage. On raw benchmarking Do loop is faster. I've sometimes encountered situatations when For loop worked faster, but I can't recall when it was.

may this be the for each?

[Jacob Roman]

What?!! That's odd. A = B is faster than A& = B&. Look at my performance test:

VB IDE
----------------
A = B ---> 1061721
A& = B& ---> 1036673

EXE
----------------
A = B ---> 1109474
A& = B& ---> 1107244

So A = B is faster.

[nareth]

thats because they are both varient( ?)
and on the iretator it converts both varients to long first

[Jacob Roman]

Wrong. They have both been declared as Long!

And get this. I tried A = 1 as a test and check this out! Using numbers with & makes them faster.

VB IDE
----------------
A = 1 ---> 1008852
A = 1& ---> 1019759
EXE
-----------------
A = 1 ---> 1145979
A = 1& ---> 1150383

[Merri]

Well, & and the like are only support stuff from the old days, so I don't wonder if those haven't been optimized in the VB6's C/C++ based, hacked compiler.

Also, those values can have a data type. When I added # instead of &, the speed fell down from the hill. It did make a datatype conversion. But if you don't declare anything for the value explicitly, compiler will use the best possible match: Byte for a Byte, Integer for an Integer and so on. So in the end, there is no point in adding an explicit datatype for the value.