> After 1s the processor load descends visibly to 110%, which is still approx. 10% more than without these extra blocks. For my understanding this should be similar since the Subsystem is disabled. Am I missing something?
While the code within the block does not execute when the system is not enabled, there still is some computational overhead for introducing the Enabled Subsystem. If the C-Script was more complex one would expect a more significant difference between placing the C-Script in an Enabled Subsystem vs. the conventional implementation.
> Is there a better solution to stop evaluating code in order to reduce processor load?
The Enabled Subsystem is a good approach in this instance.
You should take a holistic approach to improving your model execution - e.g. simplifying the model if possible, removing unnecessary scopes/displays, and harmonizing sample times. There also is the RT Box model optimization tutorial on our website which might be helpful to review the basics.
Regarding sample times, one very minor opportunity in this case is to change the Delay block's Sample Time parameter from 1 second to Ts. With that change an internal counter is not need to ensure the event happens every 1s, but every loop. You can always do a diff between the C code generated from two models to see the impact.
The improvement again depends on the complexity of the task vs. the overhead to ensure it only happens periodically. It also depends on what percentage that particular portion of the model contributes to the overall processor load.
> Btw, the RT Box never runs into an overflow even when running at 120%?!
The reported value is the peak processor load over several time steps, and therefore can exceed 100%. The processor load will vary from time-step to time-step based on the model and/or the RT Box hardware/firmware effects. The RT Box will halt on error only following several consecutive overruns based on the Overrun Limit specified in the Coder Options window.
Note that when the overrun occurs the RT Box outputs are not updated at the end of the time-step. Additional latency and potentially integration errors are introduced in the loop, so running at over 100% is probably not recommended.