The Xojo shell class is inefficient

Trying to track down a CPU usage issue with my application, I came up with the idea that the Xojo asynchronous shell class might be the culprit (as it launches a task to run in the background, to which I then collect the result after a period of time).

In my first test, the Xojo Shell class uses 34x CPU time compared to a simple NSTask (via declares, so I know what’s going on). I expected the Xojo shell to use more CPU, but not to this degree.

I proved this by pragmatically getting CPU time of the test application before running the test and then comparing it with the CPU time after the test. In a 1 minute test, the Xojo shell used 3.44 seconds of CPU time. While the NSTask used 0.1 seconds.

The other nice thing about using NSTask to launch tasks, is that I can schedule them to run on efficiency cores of the M series processors, thus reducing energy usage even more :slight_smile:

I wanted to share the results as I assumed the class would use more CPU time, but not that much more.

3 Likes

You could try ShellMBS class instead.

I’ve added “Interrupt wakeup monitoring”.

Shell: 39,537 wakeups in 1 minute.
NSTask: 3,649 wakeups in 1 minute.

Compiled App:
Shell: ~ 50,000 in 1 minute.
NSTask: ~ 12 in 1 minute.

While running the Shell test, I’ve seen the following message posted to the console log.

symptomsd[227:6d239c] [com.apple.symptomsd:debuggability] RESOURCE_NOTIFY trigger for My Application.debug [61292] (45001 CPU wakes over 143.00s seconds, violating limit of 45000 CPU wakes over 300.00s seconds)

Which also causes crashReporter to write a wakeups_resource.diag report… Oh boy…

Erm… Thanks… But I’m probably going to stick with Declares for the time being.

That wouldn’t surprise me as NSTask launches processes and Xojo’s Shell class starts a shell environment (which can then be used to launch processes).

1 Like

This makes perfect sense, it’s like using a sledge hammer to hammer in a nail for hanging a picture. You can use it this way, but it’s not the most efficient.

I’m plenty pleased, I’ve cleaned up some other things with the test application and it now uses 0.01 seconds of the minute with only a dozen wakeups.

Tomorrow I begin looking at how to integrate this into the application.

1 Like

… which brings some benefits, but in general has the CPU usage issues Sam noticed.
I worked around this by adding a SleepMBS with a short delay to my helpers’ main loop’s macOS branch additional to the usual DoEvents. That got me rid of the wakeup alerts and reduced usage to 0.1 to 0.3, depending on the helpers’ actions.

1 Like

Whoa !

1 Like

It really is kinda insane to get things working as they should.

There’s no point in creating any kind of feedback, as it’ll just get closed in two years.

I really wish Xojo cared about their one and only product.

1 Like

I get your frustration but it sounds like you’ve found (at least on macOS) a really good new implementation for calling shell functions. Maybe if you submit it to feedback it’ll get picked up for others to use?

1 Like

Maybe better ask Xojo Inc. to fix the bug?

Whether they use NSTask or execve() directly, there is no reason to waste CPU, e.g. by a polling loop there.
(and both variants are in MBS Plugins)

1 Like

If I had faith that Xojo were capable and would fix my bugs, I would instantly write a bug report and provide a sample project. The last 6 years has painfully eroded that faith, at first I just found it difficult for my reports to gain traction, then we see what they’ve wasted their resources on, then they close all my outstanding reports that they’ve ignored.

My honest assumption is that Xojo is operating on a “minimum effort, maximum impact” program. These things that affect mainly the top 2% of Xojo’s customers are not worth the effort, especially as those are the kind of people who’re capable of migrating to other languages/tools.

Sure, improved Shell efficiency would benefit everyone using the Shell class, but in reality only two developers have gone as far as to figure out it is inefficient. What the rest don’t know, won’t hurt them right?

There was already a Feedback for NSTask as this is secure way of launching bundled helpers with a Sandboxed application.

I know that there was also another Feedback request, so we could direct helper apps to use efficiency cores.

Edit: Sorry for such pessimistic responses.

1 Like

Please stop turning every single thread you comment on, into a sales pitch for your plugins. If someone wants to know if they can do this with your plugins, let em ask youse.

5 Likes

Does this bug affects the “Multicore(scam)” feature offered by xojo (workers)?

1 Like

Would really depend on how Workers are initiated I expect
If they are started using a shell it might
If they are started using something more native on each platform then_maybe_ not

1 Like

First time somebody responses like I got respond for Java marketing. It was that what I wanted to reach. With every single Thread we can read: wird Monkey bread Plugins you can do that.

That’s why Xojo banned me and others. Once you start complaining, they don’t want to hear it.

That said, Christian is offering you a solution but you’re not even considering it. The reason that Christian posts so much about the plugin is that it DOES so much. I trust Christian’s code. Christian a bazillion times more trustworthy than Geoff too. So maybe back off someone trying to help you.

Kinda of the same situation with Thorsten and Java. I don’t think you complained but other have. All while Thorsten just wanted to help people escape Xojo.

People need to be less rude about others trying to help.

3 Likes

I dont mind using MBS as well
I does save me time figuring out the declares
So this isnt a post about “dont use MBS”

I also dislike the constant “try my plugins” that dont offer anything more than “try my plugins” as a sales pitch
And I have said almost exactly this more than once
Here. On TOF. And even as far back as the old maling lists.

If the initial reply from @MonkeybreadSoftware wasnt just try

but instead

here’s how you can achieve this using MBS and you wont have all those wake ups

plus some example code its less sales pitch and more helpful overall
much more helpful

I’d appreciate that

6 Likes

Well, the OP said that he ALREADY had a working solution with declares…

The topic was about the XOJO BUG, not an open question asking for alternatives.

I think that it is also rude trying to sell something when the thread is not open to that.

My two cents, which might be worth that much… :wink:

Personally I don’t mind Christian chiming in with his comments on MBS and I truly find this helpful. Full disclosure in that I’m already a customer so I don’t see this as a sales move, but instead showing how MBS can solve a particular problem/issue. He’s not doing a hard sell here but I understand folks might not be thrilled with any kind of a sell. But for folks who want zero selling, where does this end? Do we say that all third-party vendors can’t let folks know when their solution might be of use on a particular topic? Does this mean that recommendations for App Wrapper, Lifeboat, MBS, etc. shouldn’t be brought up?

Regarding whether or not he’s providing an alternate solution is worthy to even bring up when other solutions are already on the table, I still find this valuable. Remember that these topics of course are trying to help the OP, but there’s others following along, or might find the thread in the future and having a full discussion of all possible options would be helpful.

For this thread in particular, shell performance isn’t an issue for me, but it might be one day. As such, although I do appreciate free solutions, time is a valuable commodity and I’d much rather punt to MBS where I can, instead of trying to reinvent potential solutions on my end. In this particular case, because MBS does so much, I wasn’t aware of ShellMBS and really appreciated the link so that I could see it’s a cross-platform solution. So now at least for me, I’ve squirreled away in the back of my mind that if I ever have a shell performance issue, MBS has a solution/workaround.

1 Like