I just tried out VisualVM and it seems like we’re getting the same solenoid problems as are reported here. We’ll just cache the state for now instead of getting the state every time.
Thank you so much for you detailed response. It was this bit of magic I did not know:
-Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=172.22.11.2
But the directions are great. I will be spending some quality time this weekend working with the kids speeding things up.
… waitfornotifieralarm …
I’d say your CPU info looks great:
- loopFunc calls teleopPeriodic and then your commands without further ado
- Those commands don’t take any significant time
- LiveWindow.updateValues is called, but uses less than a percent
Yes, waitfornotifieralarm shows up with a high percentage, but as Peter explained, that’s actually good news.
It’s your loop period headroom, waiting for the next iteration.
Compare that to the overall CPU usage shown in the ‘Monitor’ tab, which is probably quite low.
What we did was put certain pieces of code in new notifiers that run in their own loops. We never get overrun issues and it was super easy to do. Made our bot more reliable. We also made sure to call sensor data and any other external data once per loop and storing that value. And then we call that variable. That way we use less time per loop.