Site
News
Files Visual Basic
Strings
Math
General
Properties
Memory
Methods Search
Testing Inline ASM-VB
Strings
Math
General
Memory Search
Using inline ASM
Submit!
News
Files Visual Basic
Strings
Math
General
Properties
Memory
Methods Search
Testing Inline ASM-VB
Strings
Math
General
Memory Search
Using inline ASM
Submit!
Module Longs vs local LongsVery interesting,
I discussed this with someone over ICQ, and decided to test it.
when you declare a Long in a sub/function, using Dim (local variable), then math operations will be performed faster then when you put the Long in a module or in the declarations section. You might think it should be different! But the fact is that it's only like this with longs and not with singles (about 20% slower!), or integers.
Also note that you should not worry now that your code is slow. This was tested with 500000 iterations..and it's 0.02sec.. so you won't notice it.
User contributed notes:
when you declare a Long in a sub/function, using Dim (local variable), then math operations will be performed faster then when you put the Long in a module or in the declarations section. You might think it should be different! But the fact is that it's only like this with longs and not with singles (about 20% slower!), or integers.
Also note that you should not worry now that your code is slow. This was tested with 500000 iterations..and it's 0.02sec.. so you won't notice it.
Declarations: Code: |
Module % faster than Local | Module (sec) | Local (sec) |
-1.6% | 0.007224 | 0.007345 |
5.1% | 0.007532 | 0.007166 |
31.1% | 0.009236 | 0.007045 |
18.4% | 0.009246 | 0.007808 |
5.2% | 0.007381 | 0.007018 |
User contributed notes:
Author: Rockoon () | Date: 20:04 04/04/2004 |
It seems to me that in the second case (the local version) that the VB optimiser will agressively optimise out any and all operations on the variable lngLongA. So that in the second case, the operations simply are not performed and you are instead only timing a call to an empty sub. This also seems to be true for many of your other time tests. Look at the assembler code that is generated to make sure its actualy performing the operation whenever you use a local dummy variable that cannot affect something outside the scope of the sub/function. I'm assuming of course that you compile with all optimisations turned on. VB's optimiser is very aggressive in regards to 'dead code'. |
|
Author: Tom (hurendo_kun at hotmail dot com) | Date: 15:05 31/05/2005 |
That's a very interesting point, but it doesn't explain the performance differential. In most cases the difference is negligible, which means the same number of operations should be performed in either case --- though, with such rapid operations, the overhead for a Public function call may account for this. |