I have to maintain a very big XOJO desktop application. I don’t have numbers as it’s hard to do with the XOJO IDE but it takes around 6-7 min to compile.
As you may think, those times make myself very addicted to coffee. I have so much spare time after pressing the run button, I think we can all agree on reducing it would enhance our productivity.
Well there are several challenges to unpack here. First of all, I know, XOJO was never designed to build such a massive application. But people still did. And as a software engineer I have to come up with a way forward to maintain it. We even introduced continues integration with Drone and XOJO - which was, frankly, just pain due to the “locked in nature” of XOJOs compiler bundled in the GUI based IDE.
Well the other thing which already would help I call a “pure XOJO based plugin mechanism”. We would be able to link modules to our code (which are written in pure XOJO and not like the current plugins in C), reducing the amount of code to compile by decomposition.
Secondly, of course the compiler could be enhanced, using multiple threads, etc. I know that’s not the easiest request to do.
I hope I get some feedback by the XOJO community if one of the two things is “in sight” in the foreseeable future. Would help to please the “long term customers” as they tend to build bigger applications (monoliths and technical debts) over time.
thanks for your reply!
The plugins initialize themselfs only once. If I compile different projects with the same set of external plugins and the compile time is much faster. So this is no concern at all.
have you set any compile optimization level in build settings shared in this project?
can you tell how much windows, classes and mega byte source code this project have?
pc specifications?
i would test the compile time with and without installed anti virus.
is the source code in a network storage or local hd/ssd?
i guess your issue is permanent but
have you looked in the resource monitor (a ms windows thing) and nothing else slow down your pc.
at ms usually this frequently updates/upgrades are annoying.
maybe test your build time at different pc’s to see if it is the hardware, os enviroment or just the ide. if this project is easy to setup in xojo ide i could measure the compile time for you with my pc and in xojo 2020r2.1
Build for 64-bit targets (uses LLVM, multi core building)
Set the “Optimization” to “default” since “aggressive” or “moderdate” won’t be of much use for most applications.
Buy a computer/mac with more cores (having only 2 is most likely to cause a major slowdown). I have x86-64 6-core macbook and it can do it plenty fast for major projects.
If you use a Windows PC then use one with 6+ cores AMD Ryzen, this builds about 2 times faster than an intel mac with the same amount of cores.
Hi Markus,
again thanks for your suggests. I reply inline:
have you set any compile optimization level in build settings shared in this project?
I made my self comfortable with those settings here:
Optimization Level** (OptimizationLevel): Used for 64-bit builds and 32-bit ARM builds/debug runs (those that use the LLVM compiler). Choices are:
Default (0): Fastest build times. This setting is recommended for most apps and should also be used when debugging.
Moderate (6): Math-related code runs faster, but builds take longer.
Aggressive (4): Math-related code is highly optimized for performance, but builds may take a significant amount of time.
I try now with default instead of moderate. That was a nice suggestion, as it brings down to nearly 4-5 min. I have to measure it more often to really give you a more elaborate answer.
can you tell how much windows, classes and mega byte source code this project have?
Too hard to tell without really parsing the whole project.
I can do this and come back later!
pc specifications?
Not relevant I guess. A computer were it should not take 7 minutes. RAM 32 GB, newest I7, etc.
i would test the compile time with and without installed anti virus.
I don’t have AV installed.
is the source code in a network storage or local hd/ssd?
Local SSD
i guess your issue is permanent but have you looked in the resource monitor (a ms windows thing) and nothing else slow down your pc. at ms usually this frequently updates/upgrades are annoying.
Should not be the case.
maybe test your build time at different pc’s to see if it is the hardware, os enviroment or just the ide. if this project is easy to setup in xojo ide i could measure the compile time for you with my pc and in xojo 2020r2.1
Thanks for the idea, but I can not give you the access to our source code (even if I would really like, but thats not my decision to go open source).
a) Run Process Monitor set up an Image Path filter for your Xojo install folder and see where the time is being spent.
e.g. Image Path begins with C:\Program Files\Xojo\Xojo 2020r2.1\
will only show programs being run from that subfolder. Use this to get a feeling for what is taking the time and see if there’s any large time gaps where for example it could be looking for missing resources and timing out (if that is even a thing)
b) Check your build steps to make sure they aren’t slowing things down.
c) move chunks of code to xojo script, with recent new features you can compile these at runtime and store the binary for future recall, only when a code chunk is changed would it need to be recompiled.
Do you compile for x84 or x64, on/for Mac or Windows?
Do you have many external resources, pictures etc.?
Check the build steps if they contain orphaned links.
FWIW, 6 to 7 minutes is not a lot. The IDE itself takes 12 minutes per minute per platform on Default and 40-50 minutes per platform on Aggressive.
To the point about Aggressive not being worth it, I’d suggest that each user asses that for themselves for each project. We were pleasantly surprised at how much of the IDE drawing code was accelerated because of how math-intensive it is.
Have you also used Analyze Project and fixed all Issues?
6 to 7 minutes is not a lot
i can’t believe that his project source code is so much that it take so long on his hardware.
i would also expect that only modifications recompile.
Fixing all the warnings made a good improvement. I thought the idea preposterous but it really worked. That makes at least 10%. Miserable work, though.
In our case any build could end up being for a public release so there’s no point in not using aggressive all the time. That and the fact that they’re typically built in the middle of the night when everyone is sleeping.
Greg, I don‘t care much about the build time for a release. But the OP says he pushes the run button. Here is waiting more than a minute too long to be productive, especially when you need to fix something and need the debugger to find out what the problem is.