speed?

[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