Speed of Apps compiled for M1 vs Universal

I have both x86 and M1 based Macs. I know the M1 supposed to be faster, but I’m wondering how much faster using Xojo to create and compile apps for M1 vs Universal.

My apps seem to run just fine and perform well enough either way. I don’t have experience writing bench mark stuff. Has anyone here done any testing in this area?

If something is barely noticeable, I’m not going to care. If something speeds way up, that’s entirely different.

Just trying to figure out if and when it makes sense to compile for X86 and M1 separately vs using Universal :slight_smile:

Universal apps are M1 apps. They are also x86 apps. In other words Xojo makes both types of app and stores them in a single app package. You shouldn’t see any speed difference between an Apple silicon app and a universal one, apart from file size.

4 Likes

So Xojo automatically runs the M1 or x86 code?

No Finder deals with that. Once the package is built Finder will run the appropriate part for the current platform.

This trick goes right back to 68K vs PPC. It lived again on PPC vs Intel. Now it is worked for Apple silicon vs x86.

1 Like

Universal apps are of course much larger. And the extra size then just sits on peoples hard drive never doing anything.

1 Like

I did point out the size difference. It should be approximately double the size. Resources are generally not duplicated. Which saves a bit of space.

This is all good information! So really, the only benchmarking would be between x86 and M1.

Which is why App Wrapper 4.5 introduced splitting, so you can give App Wrapper a single App bundle and it can output two zip files, or two installer packages, with each only only containing a single architecture.

I use this with the Sleep Aid updater, so it only downloads the correct architecture for my customers.

You should also check Xojo Issues as I’m sure there’s a feedback or two that I’ve filed over the decades asking for unused object striping and unused property striping. I think I even filed one for Xojo to refactor thier framework so it can strip out unused things from there.

If you ship Console apps as helpers, I was working on a way to get 'em to use the main framework instead of having to have their own frameworks as this can free up multiple megabytes of wasted stuff. I stopped once I realized that “2.0 All The Things” was more important to Xojo than anything else.

Edit: I’d also like to add, that for an unreleased project, I wrote the helper in Objective-C and even when compiled as a UB, it was only a couple of hundred kilobytes, instead of being nearly 7 megabytes. So there is a lot Xojo can do to optimize the size of Xojo made applications.

3 Likes

FWIW, there’s always a cost, usually in terms of size, when using frameworks like this. When you work in objective-C, you specifically include the pieces of the framework that your app needs. Xojo does the same thing except that they need to include everything that they use for their entire framework. Be happy that it’s only 7MB.

I was reading a Reddit thread on this subject, it’s kinda torn in the user community. Some like having separate downloads, while some just want one.

Trying to be complete on the subject:

And if you want to run the x86 (Intel) version of your application on an Apple Silicon Computer, select the Universal Binary (UB), → Get Information, and you will se the screen shot below (that is for TextEdit):

Then, click in “Ouvrir avec Rosetta” (Open with Rosetta)…

That’s interesting, but if you can use the universal or Apple Silicon version, why would you want to run the x86 through Rosetta? I didn’t even know that was possible.

To test if your application behaves different. You never know what your users will do with your Universal application.

I do agree you never know what the user will do, or tell you what they did for that matter. However, from a support standpoint, listing requirements for the application and it’s versions would seem to be very important to me. If it turns out a user is running it in an unsupported way, they need to be educated the proper way to run it. I can’t imagine you could flush out every possible issue by testing it this way. Just my 2 cents.

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Rick Cook.

8 Likes

And AI is an acronym for “Automated Idiot”.

Until those who train AI engines are a bit more discerning re quality of the content AI engines are fed, garbage in = garbage out.

There are several things that do behave differently on different architectures. Apple text framework for instance uses different values for text alignment, so what looks fine on x86, ends up wrong with ARM native.

If you work with declares, you may find yourself having to use the iOS values for functions instead of macOS values (Apple are not merging the OSes, it’s all in your head).

2 Likes

That was why I entered in the conversation.

Of course it’s possible, that’s what Rosetta is for. I don’t know what I was thinking.

Thanks all for the comments in this thread. I learned far more than what I was asking. All of the information will be of value to me going forward.

2 Likes