Why stays Global variable empty ?

[PB]

> And for sure, you have not use the debugger and not disable it

Did you not see "DisableDebugger" at the start of my tests?

> Compile it to an exe (use Msg Requesters to report result)

Okay, did that, and below are the results. The short variable
name tests are both shorter to complete than the longer
variable name. Every time I run the exe.



And the source I used for the exe:

Code: Select all

d=400000000

DisableDebugger

start=GetTickCount_()
For ExtremelyLongVariableNameHere=1 To d : Next
test1=GetTickCount_()-start

start=GetTickCount_()
For ExtremelyLongVariableNameHere=1 To d : Next
test2=GetTickCount_()-start

start=GetTickCount_()
For a=1 To d : Next
test3=GetTickCount_()-start

start=GetTickCount_()
For a=1 To d : Next
test4=GetTickCount_()-start

EnableDebugger

a$=Str(test1)+#CRLF$
a$+Str(test2)+#CRLF$
a$+#CRLF$
a$+Str(test3)+#CRLF$
a$+Str(test4)

MessageRequester("Results",a$)

[PB]

> Strange? Possibly to do with the overall load on the CPU at the time,
> but I expected the results to be near identical

Ah, so your own tests are showing similar results as mine. Weird, eh?

I know it's not "much" of a real-world difference, but it theoretically
shouldn't have any such difference at all. That's why it's so strange.

[luis]

> the variable name length is immaterial

Perhaps not.

It is, independently from your results. Clearly the reason need to be searched elsewhere, starting with writing some not ill conceived benchmark.

[PB]

> It is.

Explain the results of Vera, IdeasVacuum and myself, then?

[ts-soft]

> And for sure, you have not use the debugger and not disable it

Did you not see "DisableDebugger" at the start of my tests?

Okay, my english is not so clear
Don't use the debugger!
Disable it is not the same, that will always add some code to your exe!

[PB]

> Disable it is not the same, that will always add some code to your exe

I made an exe, as did another user, and our results showed faster
execution with a small variable name than a longer variable name.
Fact. That's all I know. It's thus been proven to have an effect.

[ts-soft]

Okay, but my results shows what i expect!

---------------------------
Results
---------------------------
920

936



936

936
---------------------------
OK
---------------------------

[luis]

> It is.

Explain the results of Vera, IdeasVacuum and myself, then?
We've posted tests proving it, and you've just talked.

No, I will not explain.
I've explained why it's impossible (not improbable, it just can't happen because there is no way for it to happen, there is not the mean based on what I said above) for the length of the variable to have some influence on speed.
You wrote an ill conceived benchmark (not my job to explain to you why and your bone-head attitude is just giving more reasons against it), also I spent more time replying you in another thread for nothing, you simply went away while the discussion was on.

Also you used the word "proven" many times in your last posts, you have no idea of what that means. Seriously.
Your code has certainly not proven what you think. You should look at what you wrote, ask you some questions, try to change it, duplicate code, re-ordinate it. I gave you too many hints already.

I don't need any of this, you seem to be the one in need.

[ts-soft]

And the result with debugger:

---------------------------
Results
---------------------------
1155

1154



936

936
---------------------------
OK
---------------------------

So i think, you have only disabled the debugger.

[Tenaja]

The asm code generated is identical, with the exception of the variable names. From the ASM code, machine code is generated, and machine code has no variable names, only address locations.

; start=GetTickCount_()
CALL _GetTickCount@0
MOV dword [v_start],eax
; For ExtremelyLongVariableNameHere=1 To d : Next
MOV dword [v_ExtremelyLongVariableNameHere],1
_For3:
MOV eax,dword [v_d]
CMP eax,dword [v_ExtremelyLongVariableNameHere]
JL _Next4
_NextContinue4:
INC dword [v_ExtremelyLongVariableNameHere]
JNO _For3
_Next4:
; test2=GetTickCount_()-start
CALL _GetTickCount@0
MOV ebx,eax
SUB ebx,dword [v_start]
MOV dword [v_test2],ebx
;
; start=GetTickCount_()
CALL _GetTickCount@0
MOV dword [v_start],eax
; For a=1 To d : Next
MOV dword [v_a],1
_For5:
MOV eax,dword [v_d]
CMP eax,dword [v_a]
JL _Next6
_NextContinue6:
INC dword [v_a]
JNO _For5
_Next6:
; test3=GetTickCount_()-start
CALL _GetTickCount@0
MOV ebx,eax
SUB ebx,dword [v_start]
MOV dword [v_test3],ebx
;

The most likely reason you are getting varying results is cpu loading elsewhere, slowing down your initial test. Try reversing the order of the test...

[IdeasVacuum]

Try reversing the order of the test...

SpeedTest.exe:

Code: Select all

d=400000000

start=ElapsedMilliseconds()
For a=1 To d : Next
test4=ElapsedMilliseconds()-start

start=ElapsedMilliseconds()
For ExtremelyLongVariableNameHere=1 To d : Next
test1=ElapsedMilliseconds()-start

start=ElapsedMilliseconds()
For a=1 To d : Next
test3=ElapsedMilliseconds()-start

start=ElapsedMilliseconds()
For ExtremelyLongVariableNameHere=1 To d : Next
test2=ElapsedMilliseconds()-start

sMsg.s = "Test1 " + Str(test1) + #CRLF$       ;1351
sMsg = sMsg + "Test2 " + Str(test2) + #CRLF$  ;1365
sMsg = sMsg + "Test3 " + Str(test3) + #CRLF$  ;1335
sMsg = sMsg + "Test4 " + Str(test4) + #CRLF$  ;1336

MessageRequester("Tests", sMsg, 0)

....that made a huge difference to the consistency of the results.
Edit: I have FireFox running and I expect that makes a difference on CPU load.

[Vera]

@ Tenaja
As promissed I tested it all with debugger on or disabled and that is an impressive difference

Here's what came out on my side:

; debugger enabled - disabled
; igTEnd: 1495 - 173
; iResult: 1318 - 243

; debugger enabled - disabled
; Debug test1 ; 39477 _ 2249
; Debug test2 ; 39291 _ 1679
;
; Debug test3 ; 39359 _ 1966
; Debug test4 ; 39478 _ 1666

; debugger enabled - disabled
; Debug test1 ; 39425 _ 1702
; Debug test2 ; 39464 _ 1681
;
; Debug test3 ; 39467 _ 2035
; Debug test4 ; 39767 _ 2263

; test1: 2685 - 2677 - 1397
; test2: 4025 - 4005 - 2273
;
; test3: 4002 - 4007 - 2051
; test4: 3309 - 3373 - 1689

Thanks to everybody for jumping to my aid .. And maybe these results can make you smile.

I am aware that the speed in itself is a serious issue depending on what has to be achieved. But as long I have no intention to write a new internet search machine or a high-end animated game I'm content to pick up the essentials like pointers are quicker than strings ....

I listen closely to what I read on the forums and keep quiet most of the time. Still at times it should be allowed to leave a remark on an observation that should not bring me into trouble because the obvious assumtion doesn't hold what enhanced knowledge tells.

~ Vera

[juror]

> Disable it is not the same, that will always add some code to your exe

I made an exe, as did another user, and our results showed faster
execution with a small variable name than a longer variable name.
Fact. That's all I know. It's thus been proven to have an effect.

One or a few tests do not constitute proof. Try a statistically significant series of tests varying the length, order of variables, etc.

There are too many variables which you have no control over to say your results constitute "proof".

[PB]

> No, I will not explain

Fair enough, I guess. A shame, though.

> I spent more time replying you in another thread for nothing,
> you simply went away while the discussion was on

I obviously forgot about it due to real life. Point it out and I'll reply.

[Fred]

The variable name length can't be the cause of the slowdown, as it isn't stored in the final executable: once compiled all is resolved internally in an address, the name is dropped.

Here the speed test with debugger off (not DisableDebugger as it's not the same):

---------------------------
Tests
---------------------------
Test1 999
Test2 999
Test3 999
Test4 999

---------------------------
OK
---------------------------

Which is expected.