Why stays Global variable empty ?

[Vera]

Hello,
again I crossed an issue With Procedure + ProcedureReturn that I can't explain myself.

I was testing around With ElapsedMilliseconds and then placed it inside of a Procedure when I stumbled across the effect that the TEnd-result is not available after the Procedure had been processed although it is a Global variable.

I found out that it makes a difference if I
A - just call the Procedure itself .... [TEnd will have a result]
B - or calling the Procedure for to 'fill' the variable .... [TEnd stays empty*]

Why does this make a difference? And what is the benefit from it?

Code: Select all

Global TStart
Global TEnd

Procedure relTime()
  #Size         = 100000
  Define Space$ = Space(100)

  TStart = ElapsedMilliseconds()
  Debug TStart
  For n = 1 To #Size
    Len = Len(Space$)
    For i = 1 To Len
    Next
  Next
  TEnd = ElapsedMilliseconds() - TStart
  Debug TEnd                            ; the variable contains the result

 ; ProcedureReturn TEnd
EndProcedure


TEnd = relTime()
;relTime()                    ; this call would deliver the result
Debug "TEnd: " + Str(TEnd)   ; why does this var stay empty although it's global?
Debug TStart
Debug TEnd

* [TEnd does not stay empty] if I use ProcedureReturn AND in this case the variable doesn't even have to be made Global beforehand for to deliver the result after the process. Cross-test-example:

Code: Select all

Global TStart
;Global TEnd

Procedure relTime()
  #Size         = 100000
  Define Space$ = Space(100)

  TStart = ElapsedMilliseconds()
  Debug TStart
  For n = 1 To #Size
    Len = Len(Space$)
    For i = 1 To Len
    Next
  Next
  TEnd = ElapsedMilliseconds() - TStart
  Debug TEnd

  ProcedureReturn TEnd
EndProcedure


TEnd = relTime()
;relTime()
Debug "TEnd: " + Str(TEnd)
Debug TStart
Debug TEnd

thanks ~ Vera

[Tenaja]

All procedures return 0 unless you return a different value. So, unless you have this at the end of the procedure:
ProcedureReturn TEnd
then this TEnd will always be zero:
TEnd = relTime()

Also, if you want to return a value, you should "cast" the procedure (that is, tell PB what the return value Type is):
Procedure.i relTime()

[Thorium]

On your first example you put the return value of the procedure in TEnd, but the procedure has no return value, which equals 0, so you put the time in and then you put 0 in.

The second example looks fine, of course it does not need to be global. You implicitly declare 2 local TEnd variables. One inside the procedure and one outside. You return the value of the "inside" TEnd and put it in the "outside" TEnd.

[IdeasVacuum]

Use EnableExplicit and name your vars so that you can see what they are

Code: Select all

EnableExplicit

#Size = 100000
Global igTStart.i
Global igTEnd.i

Procedure relTime()
;------------------
;Using Global vars

Protected Space.s = Space(100)
Protected iI.i, iN.i, iLen.i

              igTStart = ElapsedMilliseconds()
              
              For iN = 1 To #Size
              
                   iLen = Len(Space)
              
                   For iI = 1 To iLen
                   Next
              Next
              
              igTEnd = ElapsedMilliseconds() - igTStart
EndProcedure

Procedure.i relTime2()
;---------------------
;Using Local vars

Protected Space.s = Space(100)
Protected iI.i, iN.i, iLen.i, iTStart.i, iTEnd.i

              iTStart = ElapsedMilliseconds()
              
              For iN = 1 To #Size
              
                   iLen = Len(Space)
              
                   For iI = 1 To iLen
                   Next
              Next
              
              iTEnd = ElapsedMilliseconds() - iTStart
              
              ProcedureReturn(iTEnd)
EndProcedure

;Using Global Vars
relTime()
Debug "igTEnd: " + Str(igTEnd)

;Using Local Vars
Define iResult.i = relTime2()
Debug "iResult: " + Str(iResult)

End

[Vera]

All procedures return 0 unless you return a different value.

so you put the time in and then you put 0 in.

wow ~ that was the jumping point I missed

You implicitly declare 2 local TEnd variables.

oh - I wasn't aware about that double declaration.


Also thanks for the other valuable hints and IdeasVacuum summing it all up in one clear example

That too finally answers a very old troublesome question, why in some codes I find ProcedureReturn...ing a 'namedVariable' of which I could never find its correspondence in the rest of the code being asked for. (referring to: iTEnd and iResult.i)

Thanks for your quick and helpful responses ~

btw - on a sidenote: playing with this examples I too experienced that the lenght of the variable-names themselves have an impact on the processing time. The shorter the quicker.

[ts-soft]

btw - on a sidenote: playing with this examples I too experienced that the lenght of the variable-names themselves have an impact on the processing time. The shorter the quicker.

That is bullshit
There is no different!
(only if you use the debugger for timecount)

[luis]

@Vera

In very simple terms with some imprecisions:

When the program is translated to ASM, the variables are just assigned to sequences of bytes in memory.
The bigger is the data type, the more bytes of memory are required.
For example a .l will require 32 bits (4 bytes) while a .q will require 64 bits (8 bytes).
The machine language instructions generated by the assembler (who processed the ASM file generated by the BASIC compiler) access those bytes through their assigned addresses, the original name used in the PB source is no longer required.
So the variable name length is immaterial, there is no trace of it in the final machine language, only addresses.
What can make a difference in speed is the size of the data accessed, and the addressing method utilized.
There is more than one in machine language and each one is more indicate than another depending on the type of data accessed (a single variable, a string of bytes, an array, etc.) and/or the type of algorithm accessing the data.

[Tenaja]

btw - on a sidenote: playing with this examples I too experienced that the lenght of the variable-names themselves have an impact on the processing time. The shorter the quicker.

You need to disable the debugger if you want an accurate time measurement.

[Vera]

That is bullshit

That is insolent and cocksure offensive.

[Vera]

Thanks luis,
I understood that

What can make a difference in speed is the size of the data accessed, and the addressing method utilized.

Ah - this might also explain, why re-running the code various times with only minimal changes, it also returned differences in the debug-results.
So it might just have been a coincidence that the observed difference when I shortened the names was significant against the other observations.

You need to disable the debugger if you want an accurate time measurement.

It dawns to me I've heard about this before, still it's good to be remembered and I'll give it a go.

However - I might be a Formular 1 fan and at times had wanted to become a test pilot - BUT fighting about who might have the speediest routines is not in my interest.
I'm out of contest anyway - or may I say - my PC is

thanks for your support ~ Vera

[Tenaja]

... - this might also explain, why re-running the code various times with only minimal changes, it also returned differences in the debug-results.
So it might just have been a coincidence that the observed difference when I shortened the names was significant against the other observations.

If you did have the debugger on, back-to-back test results will most likely vary wildly even with no changes. The other random things that slow down the debugger are huge compared to the speed hit of using "inefficient" variables.

[Thade]

btw - on a sidenote: playing with this examples I too experienced that the lenght of the variable-names themselves have an impact on the processing time. The shorter the quicker.

That is bullshit
There is no different!
(only if you use the debugger for timecount)

That is bullshit

That is insolent and cocksure offensive.

cocksure = schwanzsicher? Wo hast du das her?
Besides the terms you are using here ... if you make a statement (variable names - the shorter the quicker) it should be correct or it is ... bulls***

[PB]

> the variable name length is immaterial

Perhaps not. When I run the following test, the shorter variable
loops are always finished slightly sooner than the longer names.

Maybe someone can point out if I'm doing something wrong?
Because it seems to match Vera's claim... every time.

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 ; Short name (a).
test3=GetTickCount_()-start

start=GetTickCount_()
For a=1 To d : Next ; Short name (a).
test4=GetTickCount_()-start

EnableDebugger

Debug test1 ; 2090 ms
Debug test2 ; 2106 ms
Debug ""
Debug test3 ; 1763 ms
Debug test4 ; 1747 ms

[IdeasVacuum]

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

Code: Select all

d=400000000

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 ; Short name (a).
test3=GetTickCount_()-start

start=GetTickCount_()
For a=1 To d : Next ; Short name (a).
test4=GetTickCount_()-start

MessageRequester("Test1", Str(test1),0) ;1328ms
MessageRequester("Test2", Str(test2),0) ;1328ms
MessageRequester("Test3", Str(test3),0) ;1125ms
MessageRequester("Test4", Str(test4),0) ;1109ms

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

[ts-soft]

952
936

951
936

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