Performance Profiling Surge #556
Comments
|
Hmm what a good and worrying report. I wonder what it's doing. I do notice some non-zero cpu clip at idle also. |
|
OK I took a peek at this using the macOS sampling profiler on the release where 5773 is the pid of the host. Found the time used was about half drawing and half in the processing loop Didn't dig into the processing loop but the drawing time came a lot from something called 'background refresh' type stuff in NSView. (This was all mac). And then I noticed something which seems to be worrying. The background image draws on every idle. So if I place a print in CScalableBitmap::draw it gets called every idle loop. More to investigate here, but that's definitely an issue. |
|
The stack that gets us to the background draw is |
|
OK I checked on linux also and it is also drawing the background every idle. Here's the linux stack so this isn't an navies problem; this is a CViewFrame problem of some sort. That's aggravating. I'm going to tag this one vstgui since it at least has a vstgui part. (There may be other things running the CPU high; like I said I didn't walk as far down the AU processing instrumentation thread) |
|
note it may also be that surge is calling invalid() in too many places. Worth looking at that as a possibility too before diving head first into vstgui code. |
|
Okely dokely so here's a bit more information We invalidate the VU meter on every ::idle. That makes sense. It calls but that draw rect clipping forces the entire background to redraw. All of it That's pretty clearly not optimal. Explains why some CPU is leaking there. I think that's a VSTGUI bug - it should also minimally redraw the background image. But am not 100% sure. |
The VU Meter was a cause of substantial idle load. In a 30 second timer sample, a full half second was spent drawing background images - as much time as was spent filling up the audio buffer with no sound. There were a couple of key reasons for this: 1. The VU Meter invalidates every idle even if value hasn't changed 2. When the VU meter invalidates even legitimately it forces a full repaint of the background image into a clip rect because that's what VSTGUI::CViewContainer does So - somewhat unsatisfactorily in the second case - this diff fixes those by only invalidating when value changes (which is great for idle) and supressing the background image repaint using knowledge of the placement of the VU meter (which is fragile and unsatisfying but the only option we have given the protection of VSTGUI::CFrame's final status and so on). While at it, replace the pixel painted edges so the VU meeter has a better boundary when zoomed. Closes surge-synthesizer#639 - Re-Implement VU Meter Addresses parts of surge-synthesizer#446 and surge-synthesizer#556; performance and pixely bits
The VU Meter was a cause of substantial idle load. In a 30 second timer sample, a full half second was spent drawing background images - as much time as was spent filling up the audio buffer with no sound. There were a couple of key reasons for this: 1. The VU Meter invalidates every idle even if value hasn't changed 2. When the VU meter invalidates even legitimately it forces a full repaint of the background image into a clip rect because that's what VSTGUI::CViewContainer does So - somewhat unsatisfactorily in the second case - this diff fixes those by only invalidating when value changes (which is great for idle) and supressing the background image repaint using knowledge of the placement of the VU meter (which is fragile and unsatisfying but the only option we have given the protection of VSTGUI::CFrame's final status and so on). While at it, replace the pixel painted edges so the VU meeter has a better boundary when zoomed. Closes surge-synthesizer#639 - Re-Implement VU Meter Addresses parts of surge-synthesizer#446 and surge-synthesizer#556; performance and pixely bits
|
OK with the VU meter fixed if I pop it up in hosting AU and use init sine and click latch so it just pumps sin wave out through the graph and sample for 30 seconds, the profiler only catches us in a stack about 860ms of the 30,000ms. That's pretty good. And the UI is way dropped. 50% in the audio thread, 15% in miscellaneous host threads (I'm using "Hosting AU") and 35% in the UI thread. Drilling down the audio thread, seems half of it is overhead (move buffers around) but of the 410ms sampled here's the timing once you get down to SurgeSynthesizer::Process
|
|
Fascinatingly our audio render time of 270ms has 41ms - which is what, like 15% - just doing SurgePatch::copy_scenedata and SurgePatch::copy_globaldata The code mentions that the copy global data takes a great deal of CPU in debug mode. Curious. Anyway I'm going to leave this alone until 1.6.1 I think now I have fixed the draw problem. But I think hitting the code with a profiler or two on a couple of interesting situations may show us a lot. |
The VU Meter was a cause of substantial idle load. In a 30 second timer sample, a full half second was spent drawing background images - as much time as was spent filling up the audio buffer with no sound. There were a couple of key reasons for this: 1. The VU Meter invalidates every idle even if value hasn't changed 2. When the VU meter invalidates even legitimately it forces a full repaint of the background image into a clip rect because that's what VSTGUI::CViewContainer does So - somewhat unsatisfactorily in the second case - this diff fixes those by only invalidating when value changes (which is great for idle) and supressing the background image repaint using knowledge of the placement of the VU meter (which is fragile and unsatisfying but the only option we have given the protection of VSTGUI::CFrame's final status and so on). While at it, replace the pixel painted edges so the VU meeter has a better boundary when zoomed. Closes #639 - Re-Implement VU Meter Addresses parts of #446 and #556; performance and pixely bits
|
OK a bit more usefully you can run this in headless mode with the stress test and you see where times going. Interestingly creating a surge and loading the data takes some time but remember we are "playing" faster than audio rate here. Purposefully putting CPU to 100%. Hotspots when you do that include "WaveTableOscillator::convolute" "Effect:ringout" and all the "ProcessFBQuad" routines. I'm going to change the title of this issue to "Performance Profiling Surge" since I think a lot of the 0 CPU things are fixed with the UI change I made. Will leave this here for people to pick away at if they want.
|
baconpaul
changed the title
The VU Meter was a cause of substantial idle load. In a 30 second timer sample, a full half second was spent drawing background images - as much time as was spent filling up the audio buffer with no sound. There were a couple of key reasons for this: 1. The VU Meter invalidates every idle even if value hasn't changed 2. When the VU meter invalidates even legitimately it forces a full repaint of the background image into a clip rect because that's what VSTGUI::CViewContainer does So - somewhat unsatisfactorily in the second case - this diff fixes those by only invalidating when value changes (which is great for idle) and supressing the background image repaint using knowledge of the placement of the VU meter (which is fragile and unsatisfying but the only option we have given the protection of VSTGUI::CFrame's final status and so on). While at it, replace the pixel painted edges so the VU meeter has a better boundary when zoomed. Closes surge-synthesizer#639 - Re-Implement VU Meter Addresses parts of surge-synthesizer#446 and surge-synthesizer#556; performance and pixely bits Former-commit-id: 0e650308bda2a949e7c32265c3c534c9252835ec [formerly b51bdd2] Former-commit-id: 075d28ec6fb51087fe96dcac3aa76def95574427 Former-commit-id: ce8d1c8ea41323ee2fce9dab210c644cbc9de14a
|
I should move this information to the doc/ folder on how to profile on a mac and then close this issue. |
report from KVR: (
https://www.kvraudio.com/forum/viewtopic.php?p=7310445&sid=74fe7926c1b5f832ffcbcbb4cd8ed8af#p731044 )5
i recently try official v152 build from friend, for compare, so, my assumptions were confirmed - by some reason new version load cpu already in initial (idle) stage, just after load plugin (it's a pretty small cpu load, but strange it is). While in v152 absolutely zero cpu usage in the same idle condition. Hmm.
I dont know, maybe i miss something in settings, would be good if you check this too. Or maybe reason is known ?
The text was updated successfully, but these errors were encountered: