sdkconfig system settings

[DrMickeyLauer]

Of all the things in the ESP32 universe, the sdkconfig is scaring me the most. There are so many things to fiddle with and I'm afraid to change options since it's not always clear what they are doing.

I now have enabled CONFIG_ESPTOOLPY_FLASHMODE_QIO=y for my project which gives an enormous performance boost. Will this produce any stability issues? I'm using ESP32-S3-WROOM-1-N16R8 modules.

Another scary part is the cache configuration. Is there any benefit leaving it into default configuration or can I just bump the DATA_CACHE to 64KB and the CACHE_LINE to 64b?

[MicroController]

I now have enabled CONFIG_ESPTOOLPY_FLASHMODE_QIO=y for my project which gives an enormous performance boost. Will this produce any stability issues?

No stability problems here. Either the flash supports QIO or it doesn't. If it doesn't, you'll immediately find out.

Another scary part is the cache configuration. Is there any benefit leaving it into default configuration or can I just bump the DATA_CACHE to 64KB and the CACHE_LINE to 64b?

Smaller cache -> more available heap. If you have enough RAM to spare, go ahead and ramp up the cache size; using some RAM for the cache is better than not using that RAM at all.
Which cache configuration is 'best' depends on the behavior of the application. AFAIK, the MMU transfers data in blocks of one cache line to/from external memory. Every transfer incurs some overhead, so you want to minimize the number of transfers needed. OTOH, loading data into the cache that will end up not being used is also wasteful. If you'd often only need to access e.g. one byte from PSRAM, loading 64 bytes each time may be slower than loading just 32 bytes; if you'd often access data that spans more than one 32 byte cache line, 64 byte lines may be faster than 32.
So it all depends, and either way may be beneficial or detrimental to your application's overall performance.
If your application, or specific crucial functionality, is fast enough, I'd see no need to change the cache config.

[DrMickeyLauer]

Thanks!

Smaller cache -> more available heap. If you have enough RAM to spare, go ahead and ramp up the cache size; using some RAM for the cache is better than not using that RAM at all.
Which cache configuration is 'best' depends on the behavior of the application. AFAIK, the MMU transfers data in blocks of one cache line to/from external memory. Every transfer incurs some overhead, so you want to minimize the number of transfers needed. OTOH, loading data into the cache that will end up not being used is also wasteful. If you'd often only need to access e.g. one byte from PSRAM, loading 64 bytes each time may be slower than loading just 32 bytes; if you'd often access data that spans more than one 32 byte cache line, 64 byte lines may be faster than 32.
So it all depends, and either way may be beneficial or detrimental to your application's overall performance.
If your application, or specific crucial functionality, is fast enough, I'd see no need to change the cache config.

Makes sense, but is there any way to instrument this to make an informed decision based on letting my app run for a while with typical workloads?

[MicroController]

I guess the only promising approach is to simply time critical pieces of code and see if/how different cache settings affect the performance there, while also checking if/how much other sections may be negatively affected.

(There are hardware cache hit/miss counters in (some?) ESP's, but I'd say any numbers from those give a pretty indirect indication at best as to the actual performance of your (critical) code.)

By the way: Having gcc optimize for "speed" ("O3") may actually degrade performance vs. "Os" because gcc doesn't take into account the performance penalty incurred by larger code size. (Especially when gcc inlines, i.e. duplicates, a function's code multiple times cache misses are likely to increase. An __attribute__((noinline)) here and there can help mitigate this effect when compiling with "O3".)

[charlie choi]

I guess the only promising approach is to simply time critical pieces of code and see if/how different cache settings affect the performance there, while also checking if/how much other sections may be negatively affected.

(There are hardware cache hit/miss counters in (some?) ESP's, but I'd say any numbers from those give a pretty indirect indication at best as to the actual performance of your (critical) code.)

By the way: Having gcc optimize for "speed" ("O3") may actually degrade performance vs. "Os" because gcc doesn't take into account the performance penalty incurred by larger code size. (Especially when gcc inlines, i.e. duplicates, a function's code multiple times cache misses are likely to increase. An __attribute__((noinline)) here and there can help mitigate this effect when compiling with "O3".)

//////////////////////////////////////////////////////////////////////////////////////////////
Hi, I am also a beginner using the same module. So SDKCONFIG is important but difficult. Could you share your SDKCONFIG file? It will be a great help to me.