You’re right. Xojo did a lot of testing in this area and found that there’s a point when using more cores doesn’t decrease build time. IIRC we ended up choosing eight as the maximum, but if you have fewer cores, it’ll actually use n-1 to be sure that the system doesn’t outright lock up.
1 Like
Thank, Paul. Am I right in thinking that the front end parts on macOS are basically everything up to the point where we see multiple houdiniassistant processes starting up?
It’s a shame to hear that taking advantage of modern, multi-core CPUs for this part of the process would be so difficult: I’m definitely feeling envious of the big speed boost that developers who spend all of their time in Xcode saw from Apple Silicon 
I don’t know if you’re able to share anything about how long it takes to launch a debug build of the IDE, but I hope that this is one of those cases where the Xojo team would benefit from the work put into improving this, in the same way that the recent improvements to the speed of saving text projects were prioritised because of your own experiences.
2 Likes
We see the same situation here. Our main project has round about 805 classes, 250 modules, 1m lines of code, 12428 Methods) and xojo needs round about 2 minutes to run a debug build on a core i9 - 6 core 2,9 GHz MacBook pro with 32 gb and ssd. 90 % of the time seems to be used by the front end part of the process.
I think that it depends on how many objects, classes and modules the project has, to benefit from multiple cores. Actually I can imagine that the front end could also benefit from multiple cores being used, at least when the project is as big as ours.
Calculating the time wasted… assuming 30 Debug-Sessions a day a developer spends 1 hour waiting for the debug run. If you have eight developers on the payroll, you pay one developer for just for waiting…
So please xojo rethink your compile process 
1 Like
670 project items on iMac from 2018:
1 min 10 seconds without codesign
2 min 15 seconds with codesign
Why does the codesigning take so long? Must do some checking.
@Daniel_Fritzsche : do you have all the “pragma unused” in place? That improves compiling by 10-20%.
I haven’t dared try to quantify that for the days where I’m running lots of debugging sessions 
Yes.
On my Mac mini i7, running the IDE from source code with an empty cache takes about 3 minutes. Subsequent runs take about a minute since the IR cache is mostly full.
Obviously this is slower than we want. We are researching what can be done to speed things up and did introduce a new build process in 2022r1, which is a step in that direction.
Great, thanks Paul: I’ll keep my fingers crossed.
With my desktop project, running a debug build consistently takes about 90 seconds unless I use a new version of Xojo, MBS plugins, or hit the “Clear Caches” button. In that case, the first run takes ~240 seconds and the difference is accounted for by the plugin preparation progress bar. Does that indicate that there might be something in my project or a bug that’s preventing caching from helping my debug builds?
I wonder if this might be biting you:
https://tracker.xojo.com/xojoinc/xojo/-/issues/64800
4 Likes
Paul, you have made me very happy: switching to x86 only cuts the time taken to run a debug build to 1/3 of the time it takes to run a Universal build.
But that bug still being open after being labeled as reproducible a year ago (according to Issues) is… not ideal. I’ll add a link to this thread to it in the hope that it helps it get bumped up the queue.
1 Like
Well, there is still a lot that could be done on all the levels.
The code to prepare Xojo project for LLVM parser, could be optimized to be quicker.
e.g use a dictionary instead of looking for values with loops. Maybe check if you could output less code.
The Xojo code parser for LLVM could be optimized to output less IR code, e.g. see my feedback cases about extra nil object checks. or annotate it better or LLVM, so it can later remove extra stuff.
And that code could is in C++, so it may also be run threaded.
Lots of ideas, but since we can’t look inside the code, we can’t point to an exact spot.
4 Likes
well one could argue that the management of production is not organized well.
compiling all day long one big monolitith app is not such a good idea. you can have external modules/class that can be debugged in small apps using shared libs with little controls
so you compile +10 times per day a small app, not the big one.
then you integrate the new stuff and compile the big one only couple times
2 Likes
Thank you Paul… That helps a lot… just 40 seconds now for a debug run… 
You are going of topic and argue without knowledge. Of course we organise our code with modules. If you have red my post:
Our 250 modules are all git submodules, maintained separately in about 50 git repositories and shared over several projects. I guess that not many users are organised in that way. But when it comes to bugs in the final application you have to debug it until you understand where the problem comes from.
But coming back to the original topic… xojos compile process can be optimised…
Without this bug, the time used for compilation is way better than before and the use of multiple cores may not speed up things when incremental compilation works…
3 Likes
recent tests leads me to this conclusion:
once in a while, boot my Mac with the Command-Option-P-R keys pressed. Wait until 5 reboot/boot sound.
for time consuming tasks, never use USB (A / B) Hubs, they slow the read/write process to < 36kbs (I use Blackmagic Disk Speed Test.app for testings);
SSD drive are concerned, so use USB 3 connectors.
Never use XML (you may do an export and forget the Recent is an XML project)… I’ve done that.
Never use for a long time an SSD where the available room is low (< 50 GB)…
Of course, other strategies exists (like prototyped features in a simple project, debug it and incorporate it in the main project once it is debugged, when possible).
While I agree, when you have a dozen of USB drives, a printer, a scanner and yet other devices, you have not much choice than using an USB hub (or otherwise, you keep swapping your plugged items all day long).
Would it be possible/feasible for Xojo to allow the editing of separate Project windows while one project is being Debugged/Built? I get through a lot of Podcasts during debug compiles when I could be editing a different Project!
3 Likes
You don’t launch two copies of the IDE, e.g. two different versions?
Good idea, but why are Debugging and Building app-Modal anyway?
With the amount of RAM quickly taken by the IDE, you must have a lot of RAM on the computer to use this trick.
You’re so right! Obviously, my command of English is not as complete as I would have imagined. If I dared write something in your native language, I would be all over Grammarly–and Google translate, and a good online dictionary. Despite my occasional lapses, I am confident of my ability to transmit information correctly without creating too much work on the part of the receiver. But it’s still a good idea. My Mac and Phone and email app and word processor are all engaged in an active and often intrusive campaign to save me from myself and correct what they think is objectionable grammar or spelling. I already spend too much time trying to ignore them.
Yet, your suggestion is sound. Though I would rather be wrong once in awhile than succumb to over-reliance on these tools, it is probably false pride more than logic that drives this decision.
Thank you for your thoughts and for your excellent editing tips.
fritz