Reduce compile time

General
22

IF this is possible, extract a feature and place t in a simple test projetc.

Then debug that feature.

Once done, copy it back to the main project, test it there.

When OK, take another feature and go ahead ‘till all is OK.

I usually do that in the other order:
develop a feature in a simple project,
once debuged and working fine,
I incorporate it into the main project,
test it there

and so on.

Also: you may remove the icons (keep the 64 or 128 only), so you will keep time (for save / load). At final buld time, it will be easy to add them back.

I hope this will help you.

1 Like
23

This is the method I use A LOT, except I will make the object external, so it becomes shared between the two projects.

24

maybe conditional compilation can also help. the compiler skip this source code then :slight_smile:
could be useful for testing some parts of the app.
＃If…＃Endif
DebugBuild

25

But the code of the new feature is not isolated from the project (conflict can arise).

If you use a blank project, and the code works, a trouble that appears once incorporated in the main project gives you clues for the trouble…

And doing the simple way is often a good solution. :wink:

26

I am confused. When you do a “run” rather than a “build”, I thought the compiler automatically switched to default.

27

Debug is always default.

28

Really? I keep mine set to default and my build script sets it to aggressive when I want to make an actual build. I swear I could tell such a night and day difference in my run times that I didn’t consider the possibility that it was default on run.

29

Thanks for this basic idea. But oc it’s not that simple.
We started modularizing very late. Currently, for seperatable concerns, we do that using git submodules.
But still, it’s not so convenient.

Best.

30

Well a debug compiles at the same speed (±) as default even if you put it to aggressive so it’s probably always “default” for debug builds.

Quote from the docs:

  • 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.

This page:
https://documentation.xojo.com/topics/application_structure/desktop/desktop_apps.html#Build_Settings

So it states this “Used for 64-bit builds and 32-bit ARM builds/debug runs (those that use the LLVM compiler).”
So that would mean it would be for “64-bit builds” (not debug?) and “32-bit ARM builds/debug”.

31

On my larger projects I have resorted to building models stand alone in their own project , testing them inside out with quick compile times then adding them to the main source. This has saved me hours in testing.

3 Likes