Hi everybody.
I noticed something quite strange with the debugger. Even with a very simple patch like just checking the output of a tri-wave generator with a watch node (sorry, new user, can’t attach patch), after a while the updates of the watched values become slower and slower, the debugger becomes “stuck” and it is almost impossible to just stop it… This effect is more evident if the same patch is part of a larg-ish project. If I debug this simple patch in a project containing ~20 patches essentially the debugger stops after 5-10 sec.
I am using XOD 0.21.0 on Windows 7 Ultimate
Sounds like a bug. A few details might help to narrow down the problem.
How does your PC behaves when it stucks? Does the CPU load is at 100%? Does XOD consumes much more RAM than initially? Can you stop the debug session to escape the hang? If so, does resource usage goes normal? What’s your PC configuration: processor model and memory amount?
Thanks for taking time to reply.
When debugger slows down, the rest of the PC seems ok. I just tested on both a i5/8Gb/Win8.1 and a i7/16Gb/Win7 Pro. On freshly restarted computers the performance seems better (update frequency is ok). In debug mode XOD takes up an entire core (so ~25% on the 4 cores machine and 12.5% on the eight core one). On both machines the “Working set” is around 300-400MB.
In terms of “slowing down” I noticed that if while debugging I switch tab in the IDE, it takes a while to respond when I want to switch back to the debug tab, and the debug reporting becomes very slow (values updated every few seconds) and then progressively speeds up again, as if catching up (or emptying a buffer?)…
I also just noticed that if I tick both “upload log” and “watched values” in the filter, then XOD stops reporting the watched values in the IDE, but will update them if I scroll down in the deployment pane…
In this situation stopping the debugger becomes quite difficult (it will stop, eventually… but it will take a minute or so after I press the quit button).
After quitting the debugger, cpu usage goes back to low values, but (just tested now, don’t know if this is relevant) resource usage spikes again to a full core when adding nodes to a patch or deleting them. Memory usage does not seem to be impacted.
OK, thank you, folks, for the report. Your PC’s are powerful and the debugger should not be so slow. We’ll try to reproduce and find the root of the issue.