[3.x] Optimize AudioServer::_driver_process()
#63430
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Move expensive calculations outside inner hot loops.
Notes
vital_redraws_only
mode). While turning off the audio processing completely is the most effective option for the editor, I noticed some low hanging fruit in the hot spots, which could also be useful in running games.AudioServer::_driver_process()
in the empty case, and should also be significantly faster with active audio.memset()
, but bizarrely profiling revealed it was approximately equal in speed to the old code, and wasn't as fast as the new approach here. This may be system dependent, but without evidence of a benefit to usingmemset()
I've left it out for now. It might be more advantageous with larger buffer sizes.Further Discussion
As well as changes here, it looks like most important factor for reducing CPU in editor would either be to just turn off audio, or to sleep the
AudioDriver
(for longer, as it looks like it is slept for 1ms when there is no audio), or to close PulseAudio (or whatever platform equivalent) after some silence, as suggested here: #45948 (comment)The wider problem is that we can optimize the code in the audio threads as much as we want, but if they just spin, it will just do more iterations, so ultimately we probably need to sleep / sleep more / pause threads.