Execution Speed question

Newbie. Using XOJO-2017R3 on Windows 10. I assume that this compiles the code. I got sluggish performance from my test app. So, I wrote another project with one window and one button. The Action code is:

dim t0 ,i as integer t0 = ticks for i = 1 to 1e9 next t0 =( ticks-t0)/60 MsgBox ( t0.totext)

This little gem takes 43 seconds on my machine. This is 2500 times SLOWER than the same program written in Euphoria (interpreted) and 25000 times slower than Euphoria when compiled.
I am missing something here but I don’t see what. I am not profiling the code or anything else unusual.
Any help is appreciated!
Regards,
jd

My guess… Euphoria (whatever that is)… may be detecting an empty loop and just skipping it? (just a guess)

macOS took 41 seconds in Debug and 31 compiled

with various Pragmas activated
macOS took 14 seconds in Debug and 8 compiled or 2.9x and 3.9x faster

8/1e9 = 0.000000000339 seconds per loop

Perhaps an optimized “C” program could run 0.02 seconds, but I doubt even that

Some compilers will strip the entire loop out because it has no useful work being done in the loop and the loop induction variable is not used. Basically, the compiler looks at that and goes “this does nothing anyway”.

yeah… what I said :slight_smile:

Although I just looked at the Euphoria manual… and it doesn’t seem to indicate that

Tested on Mac - Xojo 2017r3 - 64 bit Compilation - Default optimisation

Your code debugger: 33
Your code compiled: 26

I then added the following Pragmas to the top of the method:
#Pragma DisableBackgroundTasks
#Pragma DisableBoundsChecking
#Pragma StackOverflowChecking False

Debugger: 10
Compiled: 2

I then changed the optimisation to Aggressive:
Debugger: 9
Compiled: 0

Kevin… pretty much what I had done… but on macOS

for giggles and laughs

Swift 4.0 running in iOS simulator : 3.0129 seconds
Running on a 2017 iPad - 4.6358 seconds

remember desktop CPU is faster than iPad CPU

So… I am SERIOUSLY doubting that Euphoria did that in 0.02 seconds

SWIFT CODE (NOT XOJO CODE)

 print("Evaluating problem")
        let start = NSDate() 
        for i in(1...1000000000) {
            // empty loop
        }
        let end = NSDate()   // <<<<<<<<<<   end time
        let timeInterval: Double = end.timeIntervalSince(start as Date) 
        print("Time to evaluate  \\(timeInterval) seconds")

If I optimize this to use a null loop index

for _ in(1...1000000000) {

if goes faster still

iOS simulator : 2.39 seconds
Running on a 2017 iPad - 3.8150 seconds

but still 100x slower than Euphoria “supposedly” can do it

OK…
Sorry to take so long. To answer the first question, Euphoria is a general purpose rapid development language. Second, ignore my ratios of 2500 & 25000 as one has to actually include the loop in the code. Actual numbers are 43 seconds for XOJO and 3 seconds for Euphoria running in interpreted mode. Now, I am assuming that if you don’t pay money for XOJO you always run in “debug” mode. I could expect about a 1.75 times improvement by going to compiled mode. This would make XOJO run at 43/1.75 = 24 seconds. Still a long way to go and I could compile the Euphoria code for an improvement; however, with such a simple program I doubt if you would see much improvement in speed. So, my question stands… What am I missing?

Regards,
jd

you are missing reading the above posting completely…

Not sure where you came up with 1.75… when I posted I observed as much as 3.9, and Kevin managed even greater…

Kevin showed that Xojo got below TWO seconds… with proper application of compile controls

This is not an apples to apples type of comparison. You are assuming that Euphoira and Xojo should both have the same internals, both have the same error checking, both have the same debugging methods. As shown above they clearly do not.

That being said… if you feel Euphoria is better suited for your applications, then feel free, there is no obligation from or to you (or any of us)

I showed that another language (Swift) provided a whole different set of metrics for similar reasons.

But truth be told, the timing of an empty loop means nothing… what happens when there is real work to be done. Well even then I would expect vast differences in execution speed, as Xojo, Swift or Euphoria most likely all have their sweet spots. So any further comparisons of this type fall into the realm of “a game”… Who can find that one task the each language excels at in order to prove that one is “better” than the other. Its then becomes the language, the “program”, the developers style, their knowledge of optimizations techniques, and so much more.

Last post on this topic

Xojo2016r4.1
macOS Sierra
Compiled 64bit - agressive mode

1.251709 seconds

		#Pragma BackgroundTasks False
		#Pragma BreakOnExceptions False
		#Pragma DisableBackgroundTasks
		#Pragma StackOverflowChecking False
		dim t0 as double
		dim i as integer
		t0 = Microseconds
		for i = 1 to 1e9
		next
		t0 =( microseconds-t0)/1000000
		MsgBox ( t0.totext)

I had to change to microseconds to get a valid answer
Kevin probably got ZERO (see above) because it was <1second on his computer
NOTE : speed of computer has a BIG effect as well

Out of interest, I used Dave’s code as it is more accurate.

Running the code in the IDE gave the time 9.428788 seconds.
Running a built app gave the time 0.000009 seconds.
The compiled code was 1047643 x faster.

This was using Xojo 2017r3 on a 5 1/2 year old Macbook Pro 2.6GHz I7 running Mac OS 10.9

As others have already mentioned, the test is pointless as without examining the machine code generated by the compiler you don’t actually know what code was executed.

That some compilers remove loops that don’t do anything.

Euphoria probably falls into this category, so you are comparing an Euphoria app without a loop with a Xojo app that runs through the loop a billion times. Comparisons don’t get much more pointless than that.

Try it with a loop that actually does something.

I am not promoting Euphoria. It’s just a convenient yard stick for comparison purposes. Euphoria does execute the empty loop. As the number of iterations changes (X10 or X100, say) the execution time changes proportionally. Using C (gcc) instead for comparison purposes gives an execution time of 2.5 seconds. Dave S: You are, of course, correct. Benchmarking is largely pointless. Remember that this all started by the sluggish performance of a test project. The 1.75 comes from the numbers in the above posts in a effort to get a handle on how much the debugger slows the proceedings down. Since I can’t yet produce an executable I can only guess as to speed improvements. Usually, speed is not a problem, especially in GUI applications where one is just trying to interact with the user. I am interested in speed to avoid the problem of having to write external .dll code to perform a task where speed is needed; hence, as I like what I see of XOJO, what is it capable of as relates to speed of execution?
Thanks to everyone for their help.
Regards,
jd