CPU usage of Catapult goes permanently up when doing lots of reversing

See also issue #35 :

I noticed that CPU usage of Catapult goes up a lot when using reverse as described above (by keeping PgUp pressed in openMSX). CPU usage stays high even after this.

So, I bisected it and it's introduced in this commit:

730028b is the first bad commit commit 730028b Author: Manuel Bilderbeek Manuel.Bilderbeek@gmail.com Date: Fri Jul 24 21:35:19 2015 +0200

Update (reinit) parts of UI when hardware changes

Although it's doing a lot of work, Catapult can still quickly enough reinit itself when stuff changes in the hardware. So if anything changes (e.g. someone does a console or menu command in openMSX), Catapult will stay in sync.

:040000 040000 516ad7f90ec5b4dc72bf0fcbfde46fba48958812 9fc49582f73506b7cf12283d0f35548c62293ec4 M src

Checked a bit more, I can 'fix' the issue if I comment out these lines from openMSXController.cpp:

    } else if (data->updateType == CatapultXMLParser::UPDATE_HARDWARE) {
        ExecuteStart(m_relaunch); // reinit stuff now */
    } else if (data->updateType == CatapultXMLParser::UPDATE_CONNECTOR) {
        ExecuteStart(m_relaunch); // reinit stuff now */

(UPDATE_EXTENSION can be kept in.)

Perhaps Catapult is getting into some communication loop, even though I thought it wasn't. EDIT: no, just checked, there really is no abnormal communication going on while Catapult is eating 100% in seemingly idle state. Just the query for the FPS, that's all.

Hydragon tried on Windows. CPU usage didn't go so high as on my Linux system, but he did get a 'permanent' 15-20% CPU usage or so, while Catapult was doing nothing.

openMSX / wxcatapult

CPU usage of Catapult goes permanently up when doing lots of reversing #36