Real-time data performance mods #205
Conversation
mainwindow.cpp
Outdated
| ui->dispCurrent->setVal(values.current_motor); | ||
| ui->dispDuty->setVal(values.duty_now * 100.0); | ||
| mMcValues = values; | ||
| shouldSetDisplayBars = true; |
There was a problem hiding this comment.
Rename this to shouldUpdateDisplayBars
kubark42
force-pushed
the
vesc_realtime_performance
branch
from
1b93ada
to
9e5abfa
Compare
kubark42
force-pushed
the
vesc_realtime_performance
branch
2 times, most recently
from
13302b3
to
475cb20
Compare
Too high of a frequency can't be easily read and burns up lots of CPU in redraw events.
kubark42
force-pushed
the
vesc_realtime_performance
branch
from
475cb20
to
0d4136f
Compare
|
is this still relevant? or ready to merge? |
Since it's Qt 5.15 behavior on macOS, it is still relevant to macOS. It might be a resolved problem on Qt 6.x, but |
|
I think we talked about this on the discord back then. I also added some improvements since that greatly increased the performance on slow computers. This does a bit more, but the drawback is that when you leave a rt data page while sampling and go back to it the data that arrived in that time will be missing, which is why I didn't want to include this pr. I just tried it now, and when I sample RT, IMU, APP and BMS data at the same time and have the plot open on fullscreen VESC Tool draws about 1% of my total CPU (25-40% on one of the cores at worst). When the plot page is not open and sampling is active that core goes down to almost nothing. |
|
We did, here's the link to that convo: https://discord.com/channels/904830990319485030/910253910655123566/937017928417685506 Quoting from that link:
IIRC, you use Linux and thus the Qt subsystem idles substantially better for you than for macOS users. I don't think we ever discovered why Qt 5 behaves that way, but I know this problematic Qt CPU usage affects many more Qt 5 applications than just VESC-Tool. I also don't remember us finding a better solution than this PR to address the CPU issues on macOS, so to answer @Teslafly's question the PR is still relevant to a subset of VESC-Tool users. That doesn't preclude closing it, since if it's never going to get merged it doesn't make sense to leave it lingering open. The problem and work-around are documented here, so macOS users who roll their own VESC-Tool can use this code. |
VESC-Tool would consume >70% processor while idle, but receiving real-time data.
These changes address the vast bulk of the idle processor load. I see only around 12% idle, for a reduction of over 80%.
Note, however, that while viewing the real-time graph processor load is still extremely high.