oresat / CANopen-monitor

An NCurses-based TUI application for tracking activity over the CAN bus and decoding messages with provided EDS/OD files.
https://canopen-monitor.readthedocs.io/
GNU General Public License v3.0
25 stars 6 forks source link

CPU Usage Too High #78

Closed dmitri-mcguckin closed 2 years ago

dmitri-mcguckin commented 2 years ago

Describe the bug CanOpen Monitor uses too much of the CPU.

To Reproduce Steps to reproduce the behavior:

  1. Open application
  2. Add atleast one bus interface for listening

Expected behavior The application runs with an average 60% or less CPU time

Additional context The issue is likely driven by the fact that there is no sleep event inside the bus-listener handlers, causing a spin-lock behavior where the CPU is never given up by the application, save for interruption.

nickembrey commented 2 years ago

I think this might just be curses. Here's what my profiler says:

image

nickembrey commented 2 years ago

Per https://stackoverflow.com/a/15686903/5374021, I tried replacing self.screen.nodelay(True) with:

self.screen.nodelay(False)  # Enable user-input blocking
self.screen.timeout(100)

which brought the CPU time usage < 5%

dmitri-mcguckin commented 2 years ago

Yep!

This was something we enabled a long time ago because we found that updates to the pane would block on a user key-press which we don not want to be the behavior. so if I pressed f1 then f1 again, the app would take up to 1 or 2 seconds to open then close then update the info pane, which is not acceptable.

We can just add a smaller unconditional sleep() instead if it turns out it is infact the app tui though.

Sleeping for 0.01 should be enough for the usage to calm down.