Acknowledged

SDK 6.2.2 compiler optimization degradation compared to SDK4.2.x

When switching to SDK 6.2.2, compiler optimization -O 3p generates code that is significantly less optimized for speed/number of instructions than with the same optimization with SDK 4.2.x.

I have a widget that used to run fine when compiled with SDK 4.2.x, but under SDK 6.2.2 I now get "code executed too long" error without any code change (I was able to optimize my code manually to get back under the limit but it begs the question on what was changed for compiler optimization in the new sdk)

This case is on fenix 7.

Maybe this can be useful to know for other developers since one should make sure to test corner cases when close to the limit with the older sdk.

  • Thanks! I've got them and we'll get this investigated.

  • If you can generate the log.zip files, please email them to [email protected] and reference this thread in the subject.

  • The code that seems to trigger the execution too long under sdk 6.2.2 but not under 4.2.x is a set of loops with a fair amount of computation as follows:

      - large numbers of Math.sin and Mat.cos

      - large number of multiplications and additions

      - reference to nested dictionaries and multi-dimensional arrays. For example direct calls like "CachedArray[rank][Index][lineIndex][pointIndex][1]"

      - if statements with multiple conditions

    I am able to generate the log.zip files. Let me know how to use them or what to look for.

    Thanks for the response.

  • Are you able to identify which parts of your code are less optimized under 6.2.2? That might be helpful for us to investigate.

    Another thing that would be very helpful would be for you to obtain debug logs when building the same code with 4.2.x and 6.2.2. This can be done by specifying the --debug-log-level compiler argument, which you can include at the command line if building that way, or you can add it to the Compiler Options in the VS Code Monkey C extension settings. Debug logging can be set with values from 0 (errors only) to 3 (verbose logging). I'd recommend using level three, which would be set using '--debug-log-level 3'. This will output a log.zip file in the same output location as the PRG.