Code: Select all
CompilerIf #PB_Compiler_Debugger
End
CompilerEndIf
Procedure.q DiffFileTime(*StartTime.FILETIME, *EndTime.FILETIME)
ProcedureReturn PeekQ(*EndTime) - PeekQ(*StartTime)
EndProcedure
Global.FILETIME KernelStartTime, KernelEndTime, UserStartTime, UserEndTime, Dummy1, Dummy2
Global.q kt, ut, cnt
Global x, y, z, a, b, c, w, time
Global test$
SetPriorityClass_(GetCurrentProcess_(), #REALTIME_PRIORITY_CLASS)
SetThreadPriority_(GetCurrentThread_(), #THREAD_PRIORITY_TIME_CRITICAL)
;#code = 0 ; While ... Wend
#code = 1 ; For ... Next
time = timeGetTime_()
GetThreadTimes_(GetCurrentThread_(), Dummy1, Dummy2, KernelStartTime, UserStartTime)
CompilerIf #code
!align 4
For z=1 To 1000
a=x
b=y
c=z
w=a
a=b
b=c
c=w
test$ = Str(a)+","+Str(b)+","+Str(c)
cnt + 1
Next
CompilerElse
!align 4
z=1
While z<1001
a=x
b=y
c=z
w=a
a=b
b=c
c=w
test$ = Str(a)+","+Str(b)+","+Str(c)
cnt + 1
z+1
Wend
CompilerEndIf
GetThreadTimes_(GetCurrentThread_(), Dummy1, Dummy2, KernelEndTime, UserEndTime)
time = timeGetTime_() - time
kt = DiffFileTime(KernelStartTime, KernelEndTime)
ut = DiffFileTime(UserStartTime, UserEndTime)
CompilerIf #code
MessageRequester("Result: For ... Next", Str(cnt) + #LF$ + StrD((kt + ut) / 10000) + " ms (thread time)" + #LF$ + Str(time) + " ms")
CompilerElse
MessageRequester("Result: While ... Wend", Str(cnt) + #LF$ + StrD((kt + ut) / 10000) + " ms (thread time)" + #LF$ + Str(time) + " ms")
CompilerEndIf
it's enough this code to see you wrong
and i think for..next at 9 000 000 will crash .... that's happening with for..next cycles ,are limited!!!
is no need to run it by millions times is need to make a sample block code to calculate something
and you will get MY RESULTS .... for..next is slower than while wend
MORE THAN .... YOUR MEASURE METHOD IS FOR ONE TIME EXECUTION , THAT IS WRONG!!!! YOU NEED TO EXECUTE THE CODE BY MORE T TIMES DELAYED BY 1 MILLISECONDS THEN TO CALCULATE THE TIME FOR 1 MED TIME
1 TIME EXECUTION YOU GET A WRONG ANSWER
TRY TO MEASURE BY 100 TIMES
BY 1000 TIMES ....
the block you are measure is a 10000*1000*1000 *{block execution time} yes !!! but the time execution you obtain is arbitrary , is one execution time of this script , so api windows doesn't measure perfect the real time by imperfection of system host,an system host cannot be perfect! so measuring by 1000 times the same script with that measure method can be much better but not 100% perfect.
THEN tm= [OBTINEDtimeForTexecutions /T]
(tm = relative execution's time,wich is great because we talking about relativity in purebasic
)
wich is the Correct result for T execution times
(WHY ???? because the processor/the system where you try the script can be busy with other thinks)
anyway if you try this on windows why you don't use this .. ?
taskkill /F /IM "explorer.exe"
and on the script was finish :
start explorer.exe
will be more precise! but Precise<>Perfect ! do not forget that!
so your script isn't an example to demonstrate the speed of the for..next and while...wend
for this reason i repeated the execution and the time prelevation by manny times ...because are inexact methods to get the real execution time ,because is ONLY A THEORETIC EXECUTION TIME ,a false result ,a percent probability of THE REAL TIME EXECUTION(on a imaginary system , an imaginary processor that works perfect).
from 1992 when i write the first script without to see a computer first believe me i sow history !!!
sorry we speak about time's execution relativity in purebasic , but the facts are right this!
your original script to talk about precise results is need it to execute it by 1000 for while..wend one by one then to sum the results and to divide them by 1000 ,then the same for for..next and to compare the results (with explorer.exe out and manny services closed)
