PureBasic Forums - English

Posted: **Sat Dec 06, 2014 2:08 pm**

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

Posted: **Sat Dec 06, 2014 2:19 pm**

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()

Posted: **Sat Dec 06, 2014 2:34 pm**

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.

Posted: **Sat Dec 06, 2014 2:48 pm**

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

Posted: **Sat Dec 06, 2014 4:30 pm**

Tenaja wrote:All procedures return 0 unless you return a different value.

Thorium wrote:so you put the time in and then you put 0 in.

wow ~ that was the jumping point I missed

Thorium wrote: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.

Posted: **Sat Dec 06, 2014 5:59 pm**

Vera wrote: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)

Posted: **Sat Dec 06, 2014 7:14 pm**

@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.

Posted: **Sat Dec 06, 2014 7:45 pm**

Vera wrote: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.

Posted: **Sat Dec 06, 2014 11:08 pm**

ts-soft wrote:That is bullshit

That is insolent and cocksure offensive.

Posted: **Sat Dec 06, 2014 11:12 pm**

Thanks luis,
I understood that

luis wrote: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.

Tenaja wrote: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

Posted: **Sun Dec 07, 2014 12:32 am**

Vera wrote:... - 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.

Posted: **Sun Dec 07, 2014 2:47 pm**

ts-soft wrote:
Vera wrote: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)

Vera wrote:
ts-soft wrote: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***

Posted: **Sun Dec 07, 2014 3:10 pm**

> 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

Posted: **Sun Dec 07, 2014 3:18 pm**

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.

Posted: **Sun Dec 07, 2014 3:19 pm**

Debugger wrote:952
936

951
936

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

PureBasic Forums - English

Why stays Global variable empty ?

Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?

Re: Why stays Global variable empty ?