Hello everyone,
Happy new year.
I have a module that is running very high on CPU. I have tried disabling parts of it, but nothing seems to be making much of a difference. It is a big module, with multiple parts and lots of knobs. Maybe someone has been through this before and could share with me some steps on how to run a profiler on the code so I could find what is taking most of the time?
Thanks a lot, Marcelo.
A while back I did some profiling on Linux and found a hot spot in…nanosvg? I suggested an optimization and the maintainers of the library included a version in the library. @Vortico seems to be tweaking things over the past year as well,and the app feels like it handles a larger module load before it starts breaking up.
If you can use Linux to build and test,you can Google gprof to get instructions on profiling. On other platforms there are other tools, but I’m not as familiar with them.
You might be able to use gprof on windows, in the Msys environment,as it’s a gnu tool like gcc. Never tried it.
Have you read my paper on writing efficient plugins? I profile everything, and so should you!
I found that creating a flame graph helped considerably, and helped me track down specific places where I was using much more cpu time than I should have been.
in my case, it was sprintf() for drawing user interface widgets that surprised me as the biggest culprit, but it did allow me to drill down and find specific issues.
I used dtrace to get my output (I’m on macOS), but you can also use perf in linux (sorry, I don’t use windows, so can’t give you any ideas there).
https://github.com/brendangregg/FlameGraph has a great walkthrough on how to create flame graphs, as well as tools for creating them - in fact the massaging tools that take the output also help organizing the call data if you prefer to analyze by hand.
good luck! feel free to ask if you have any questions!
editing to add that I didn’t recommend prof/gprof as others have, and sometimes having a nice visual call graph that you can click into to see specific measurements helps a lot more.
I only measure the time spent in module::step, and sometimes widget::draw. If they are taking longer than they should it’s easy to guess what the culprit is. Check by removing the suspect. I don’t actually use a real profiler. Always found those to be too much trouble.
There are dozens of profilers available, but my favorites are Hotspot and Apple Instruments. You can see an example of Hotspot usage in the make perf target.
I can only run Windows, but I will definitely go over all the information above. Looks like I have a lot to learn in this area.
Thanks a lot everyone.
A lot of the better tools for this are linux rather than windows. You should run Linux in a VM under windows. It’s trivially easy to do.
This is exactly my plan. I have VMWare Workstation, which should be enough to run it.
Thanks!!!
yeah, I just use the free VMWare Player. Works fine.
Does Rack run patches fine in WMWare Player? Because it doesn’t in VirtualBox.
You can use gprof on Windows/MSYS2 by adding
FLAGS += -pg
LDFLAGS += -pg
to Rack’s Makefile (and perhaps your plugin’s) and recompiling, but I find the output difficult to parse.
Good question. I use Linux mostly just to make sure the plugins come up, super basic stuff. I would be surprised if the audio performance in VMware is good, but don’t know for sure.
Yes, it does. VMWare’s support for video and sound hardware is better than Virtual Box. You won’t get equivalent performance, but it’s good enough for testing.
One thing to be aware of: VMWare treats the sound card as a removable device, so you might find it’s being treated as unplugged and you have to plug it in again via the menu.
I ended up using a completely different (triple go horse) approach:
I added the timing calculation to the points I wanted on my code, and just output the times as voltages to an output port. Measured the times as voltages on a multimeter plugin. This allowed me to quickly find points on my code where the time consumption was too big and recode/fix them.
I think I will leave profiling to the next time … 
Sounds like it could make for a good utility module or class for developers 
There is also DEBUG("someValue: %f", someValue); which will print to the console, passing values to this outside of process can also be advantageous.
The Rack v2 API has system::getNanoseconds() which uses the OS’s most precise and performant timing method available.
Niiiiice … count me in to Beta Test V2 when available. I would love to see my plugins running on it.
Once there is a stable v2 branch you can build it yourself. That’s what most people did to test drive v1 (actually I’m just guessing here).