Super-aggressive mode

I just put in a feature request for a super-aggressive compile mode here:

<https://xojo.com/issue/54306>

If you’d like to see that too, please make your voice heard.

(x)   COMPILE,  YOU B&*&^^*&^  !!!

:wink:

Maybe not quite that aggressive…

[x] I don’t care how long it takes

Just to be clear, the Aggressive setting we have now is already as aggressive as we can make it without breaking the application.

I’d love for someone to look at my Bcrypt code to see why I can’t make it as fast as other implementations. It’s one method that peeks and pokes directly into memory, so really it should be. Anyway, that was the impetus for the FR.

New feature request: Allow inline assembly language. :slight_smile:

If you want that level of control, write a plugin.

How does one specify the “compile mode”?

Look in shared build settings for a popup labeled “Optimization Level”.

I would rather vote for speeding up build to make 64bit faster than 32bit.

[quote=416259:@Christian Schmitz]Christian Schmitz 31 minutes ago Pre-Release Testers, Xojo Pro, XDC Speakers Germany

I would rather vote for speeding up build to make 64bit faster than 32bit.[/quote]

I am all for that too, but the key goal of this thread is to add a super aggressive optimization option, which could take much longer but generate a faster app. That is needed too. Add me as another supporter of this feature!

Greg mentioned that the current “aggressive” setting is the best we can get already :slight_smile:

Greg should be more like me and be willing to spend hours or even days/weeks on the problem in the hope of squeezing out another 4 ms. That’s what being committed looks like! (Er, commitment, I mean commitment.)

I respectfully disagree. Based on my experience with the LLVM compiler, we are not using a number of optimization options which make the app larger by unrolling loops, for example. That is a safe approach to optimization but makes the app larger.

Aggressive in its current form seems to try and speed up the app while making the app smaller. These two goals are often in conflict with each other. We need to have an option that simply speeds things up without addressing size.

We are using all of the optimizations that are safe to use with Xojo projects. We tried to get more out of it and found that they outright wreck the build. This included several so-called “safe” optimizations.[quote=416274:@Robert Birge]Aggressive in its current form seems to try and speed up the app while making the app smaller. These two goals are often in conflict with each other. We need to have an option that simply speeds things up without addressing size.[/quote]
That’s certainly not true for the IDE. The resulting build is definitely larger in Aggressive mode vs Default or Moderate.

Just to be clear, we’re using all the optimizations that we have empirically determined are safe to use that do not break your code. We spent many weeks testing various combinations to determine which could be used without wrecking the resulting executable. This included loop unrolling which is usually safe but not always safe. Some tests resulted in compile times measured in days. One of which resulted in a compile that was measured in weeks. Every test of different optimization settings was tested using our compiler verification test suite so we could be 100% sure that the resulting executable was in fact functioning as expected.

Put me on the side of ‘safe’ and ‘app runs correctly’ rather than the ‘1/2 second faster but takes hours and might not work’ camp. :slight_smile:

I was only kidding, but now you’ve got me thinking. I hate when that happens!

So we’re getting the “passive - aggressive” compiler mode then? :slight_smile:

That’s not multi-platform portable (ARM, x86, etc), but… Inline Clang is.

Dim i As Integer = 0

#Clang
extern int i; // defined outside this inline Clang
for (int c=0; c<3; c++) i++;
#EndClang

Msgbox "i = " + Str(i)