Super-aggressive mode

  1. 2 weeks ago

    Kem T

    Nov 29 Pre-Release Testers, Xojo Pro, XDC Speakers New York

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

    Feedback Case #54306

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

  2. Jeff T

    Nov 29 Midlands of England, Europe
    (x)   COMPILE,  YOU B&*&^^*&^  !!!

    ;)

  3. Kem T

    Nov 29 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    Maybe not quite that aggressive...

  4. Greg O

    Nov 29 Xojo Inc
    [x] I don’t care how long it takes
  5. Greg O

    Nov 29 Xojo Inc

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

  6. Kem T

    Nov 29 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    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.

  7. Robert W

    Nov 29 Western Canada
    Edited 2 weeks ago

    New feature request: Allow inline assembly language. :)

  8. last week

    Greg O

    Nov 30 Xojo Inc

    @Robert W New feature request: Allow inline assembly language. :)

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

  9. Julia T

    Nov 30 Sandy Hook, Connecticut

    How does one specify the "compile mode"?

  10. Christian S

    Nov 30 Pre-Release Testers, Xojo Pro, XDC Speakers Germany

    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.

  11. Robert B

    Nov 30 Pre-Release Testers, Xojo Pro University of Connecticut

    @ChristianSchmitz 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.

    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!

  12. Tim P

    Nov 30 Pre-Release Testers feedback://46303
    Edited last week

    @Robert B 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 :)

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

  13. Kem T

    Nov 30 Pre-Release Testers, Xojo Pro, XDC Speakers New York

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

  14. Robert B

    Nov 30 Pre-Release Testers, Xojo Pro University of Connecticut
    Edited last week

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

    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.

  15. Greg O

    Nov 30 Xojo Inc

    @Robert B 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.

    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.

    @Robert B 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.

    That's certainly not true for the IDE. The resulting build is definitely larger in Aggressive mode vs Default or Moderate.

  16. Greg O

    Nov 30 Xojo Inc
    Edited last week

    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.

  17. Derek D

    Nov 30 Pre-Release Testers Newnan, GA. USA

    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. :)

  18. Robert W

    Nov 30 Western Canada

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

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

  19. Bob K

    Nov 30 Pre-Release Testers, Xojo Pro Kansas City

    So we're getting the "passive - aggressive" compiler mode then? :)

  20. Rick A

    Nov 30 (Brazil. GMT-3:00)

    @Robert W New feature request: Allow inline assembly language. :)

    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)

  21. Newer ›

or Sign Up to reply!