Xojo's single core limitation

Due to Xojo’s current compiler, applications only work with one single core. This is a huge bottleneck for the application I am writing. My application is doing a lot of math in many threads, but the single core limitation slows down everything too much and is causing a CPU load up to 100%.

If I may believe Xojo, they come with a LLVM compiler in the summer of 2014, but I am afraid it won’t be stable enough for production before the end of 2014.

So Xojo is, unfortunately, not the platform for me at the moment.

I hope there are workarounds to use more cores (maybe with plugins ?), but after 2 weeks nonstop trying to solve this I am out of ideas and became frustrated.

I hope someone else has an idea I haven’t think of, but I am afraid I am out of luck and have to switch to a different platform (what I hate to say, because I really love Xojo).

Thank you.

I’ve never attempted multi-core programming myself, but I know Paul Lefebvre blogged about this a while back…

Take advantage of your multi-core processor

Perhaps this could serve as a workaround while Xojo is working on LLVM.

Maybe you can tell what you need.
We have various plugin functions which perform work on preemptive threads, so if you call them in a Xojo thread, you actually can get 8 cores busy.

Plus, if your application does math intensive calculations you should try doing them in XojoScript, which is already LLVM compiled, and is said to run much faster in these situations (I want to try this for a project of mine, but I almost spend no time coding…)


That are very interesting answers !!

I never thought about separated ‘workers’ running in a shell and communicating through an IPC socket.
I’ll definitely try that one and XojoScripting as well.

We’d some emailing currently about such thing already.

Its really not a compiler limitation.
The framework itself isn’t thread safe.
And thats a big job to make it thread safe - probably on the order of creating a new framework.

Good to see you have a head shot now Norman :slight_smile:

I’ve also made quite an extensive demo for solving this via multi-processing (i.e. with cmdline helper apps), and Marc wrote an article about it in his “RB Dev” magazine a while ago.

Ah, here’s my part of it: http://www.tempel.org/RB/MultiProcessing

If I may inject a related question there:

How does this work out with Web Apps?

E.g, in Ruby, several instances of the app are always running, ready to be handed a http request. They share session information via a shared resources (a file for fast key-value access and a file with a processing queue, both handled by a helper app).

Is that possible in Xojo as well, or will my Web App be limited to a single CPU there as well?

For a Web app- you can run several (like 1 per CPU core available) instances behind a reverse proxy (you can configure apache or nginx to do that) on different ports, and have the proxy do ‘sticky’ routing so the same external IP is always routed to the same internal instance. That way, you are utilizing all the cores available without much work…

This article explains it rather well I thought -


Yes, but Xojo still does not support the reverse proxy. Some things are malfunctioning, such as the map viewer.

please <https://xojo.com/issue/23891>

Sure there’s a limitation with that control right now, but it works today in many scenarios. I was just making sure Thomas was aware. :slight_smile:

Console “helper” apps are the way to go. Writing code in most languages that takes advantage of multiple cores is extremely complex and it’s easy to create hard to find bugs. In this respect, Xojo is far better for multiple core computing because with console apps it’s easy to take advantage of multiple cores and you can’t easily create those hard to find bugs.

While I’ve used the console “helper” apps in the past I’ve never been very clear on what’s the status for sandboxed MAS apps for this. Are “helper” console apps allowed in MAS Apps? I seem to recall they were as long as they were signed but I may be misunderstanding.