Has anybody benchmarked XOJO against other Basic Compilers ?

I was considering doing a port from VB.Net to another Basic compiler like XOJO or FreeBasic.

I like the IDE that XOJO provides but have been unable to find any benchmarks comparing the speed of generated XOJO code to that of the the other BASIC compilers or other languages.

My application currently has a 26 second response time in VB.Net and I’d like to cut that in half if possible.

Also does the code generated XOJO make use of multiple threads/cores?

The new Intel i7 chips out later this year are supposed to have 8 cores and I’l looking to leverage parallel code to get some additional speedup.

Benchmarking a language is a biased concept…
Programming style affects result…
Each language/compiler has its own strengths and weakneses.
What do you consider a benchmark? how fast it does a for/next loop?

So, is it possible that you could take your VB.Net code, port it to Xojo and have it run considerable faster?
Yes. (but maybe not)

Would it be advisable to port it straight across? No… I would advise learning XOJO and leveraging things it can do for you application that perhaps VB.NET cannot do.

Since XOJO is FREE to try… all you have to lose is some time, download, play with it… ask us questions about it… and then decide

In short, no. You can get around this by creating multiple helper console apps that each run on their own thread and core, but the bigger problem is breaking your task down into smaller parts that would make this beneficial. If you’re doing something such as image or video processing that might be worth it.

In general you’re far better off revising your algorithm for better speed.

Can you post the code that takes 26 seconds in VB?

Well here’s a simple benchmark:

1 Billion empty for next loops…just plain simple

for I as integer = 1 to 1000000000

Xojo -197 seconds
FreeBasic -12 seconds
VB.Net -24 seconds
VB6 - 14 seconds
PureBasic - 14 seconds
ChipmunkBasic - 19 seconds
B4J (free basic 4 java) - 22 second

Now throw some calculations or GUI manipulations between those “for” “next” tags and your time will increase.

Speed is, like dave said, partially controlled by your programming style… but some easy benchmarks like the above reveal that in a situation where billions of calculations will occur… With Xojo, you might be there a while. It all really comes down to what you’re attempting to achieve. … And Regardless, as a user of all the mentioned languages above, Xojo is still the best cross platform, “easiest to work with IDE” (in my opinion).

A lot of the benchmarks I typically see here on the forums are micro benchmarks, which I generally find useless. I don’t know of any “real-world” benchmarks to link you to.

No, there’s no support for pre-emptive threading. The recommendation is to segment your work into parallelizable chunks and spawn off an appropriate number of subprocesses that do the execution.

To underscore Matthew’s point about programming styles, I get around 65 seconds within the IDE. If I compile and use commands to turn off extra processing, like disabling background tasks, that drops to about 2-3 seconds.

Here is where the “bias” comes in

I got 42 seconds in the IDE (OSX)
but 26 seconds compiled…

but TWO SECONDS if I disabled all the background events!

How can you have different programming styles in an empty for…next loop?

Seems more likely your computer is faster?

for the record

  #pragma DisableBackgroundTasks
  #pragma DisableBoundsChecking
  #pragma DisableAutoWaitCursor
  #pragma StackOverflowchecking False
  #pragma NilObjectChecking False
  dim ms as double
  for I as integer = 1 to 1000000000
  MsgBox str((Microseconds-ms)/1000000)

2 seconds on a iMac under 10.9.2 and Xojo 2014r1.0 (compiled)

#pragma disablebackgroundtasks
#pragma disableboundschecking

10GB RAM/3GHz quadore processor/Windows 8…

I’m still at 106-119 seconds (ran 10 consecutive times that’s my range. … Perhaps mac is different?)

I can get 26-35 seconds in a Console…

A lot of languages will do that in 0.002ms, because the complier sees the empty loop and simply removes it from code :slight_smile: Hence… benchmarks for the sake of benchmarks is almost useless. Do something real and then measure the difference, and then ask if it really matters? Not many of our programs will do anything a billion times, let alone anything complex a billion times.

Some of it could be system-framework as well…I see all the time on the forums “my app only takes 11 second to run on windows and a minute on Mac” and vice-versa…

All comes down to what you’re attempting to code I guess

Well, I’m working on some stuff for MW to decode an entire genome. … that’s in the trillions… not to mention analyzing the Proteins etc while decoding ;-p lots of sub thread help. … Should only take a few minutes when complete

Actually I might. Working with complete Proteomes, digesting all the proteins into small peptides, calculating a number of properties for each …

[quote=85710:@Matthew Combatti]1 Billion empty for next loops…just plain simple

for I as integer = 1 to 1000000000

Xojo -197 seconds[/quote]

I get 2.1 seconds with a 1 billion count empty loop test in a compiled Cocoa app using #Pragma BackgroundTasks False.

In the debugger it takes roughly 10x as long. With BackgroundTasks True it takes 10-15x as long. Combine the two and you end up in the hundreds of seconds.

Try it on windows compiled. I guarantee the Windows framework is “slightly” sluggish in comparison to mac :slight_smile:

I did say “not many…” meaning there are some :wink:

Of course, there is certainly a time for benchmarking and your example would indeed be a good case example of when to benchmark.

Dave’s code compiled, running in Win7 in Parallels gives me 2.05-2.1 seconds. OSX compiled gives me just under 2 seconds. Are you sure you don’t have a couple of extra 0s in your loop? :slight_smile:

A good experiment, could be fun too, would be to implement some of the benchmarks found on the Benchmark Game, http://benchmarksgame.alioth.debian.org, and compare the results to some other languages. Of course, run those benchmarks on your own computer so you are comparing apples to apples.