[Bug] High memory usage, Mouser consumes 1.29GB memory

[ivanvanderbyl]

Mouser version

Latest

How are you running Mouser?

Official GitHub release asset

Build / asset details

Mouser Mac

Operating system

Other

OS version details

macOS 26

Mouse connection type

Bluetooth

Logitech Options+ status

• I have confirmed that Logitech Options+ is not running

What happened?

Mouser consumes 1.29 GB of memory, which is considerably a lot for what it does.

Expected behavior

It should consume <100MB

Steps to reproduce

Open Mouser
Leave it running for a day
Check usage in Activity Monitor

Device info JSON

{
  "device_key": "mx_master_4",
  "display_name": "MX Master 4",
  "product_id": "0xB042",
  "product_name": "MX Master 4",
  "transport": "Bluetooth Low Energy",
  "ui_layout": "mx_master_4",
  "supported_buttons": [
    "middle",
    "gesture",
    "gesture_left",
    "gesture_right",
    "gesture_up",
    "gesture_down",
    "xbutton1",
    "xbutton2",
    "hscroll_left",
    "hscroll_right",
    "mode_shift"
  ],
  "gesture_cids": [
    "0x00C3",
    "0x00D7"
  ],
  "dpi_range": [
    200,
    8000
  ],
  "discovered_features": {
    "REPROG_V4 (0x1B04)": "index 0x0D",
    "ADJUSTABLE_DPI (0x2201)": "index 0x14",
    "SMART_SHIFT_ENHANCED (0x2111)": "index 0x11",
    "BATTERY (0x1004)": "index 0x09"
  },
  "reprog_controls": [
    {
      "index": 0,
      "cid": "0x0050",
      "task": "0x0038",
      "flags": "0x0401",
      "mapped_to": "0x0050",
      "mapping_flags": "0x0000"
    },
    {
      "index": 1,
      "cid": "0x0051",
      "task": "0x0039",
      "flags": "0x0401",
      "mapped_to": "0x0051",
      "mapping_flags": "0x0000"
    },
    {
      "index": 2,
      "cid": "0x0052",
      "task": "0x003A",
      "flags": "0x0531",
      "mapped_to": "0x0052",
      "mapping_flags": "0x0000"
    },
    {
      "index": 3,
      "cid": "0x0053",
      "task": "0x003C",
      "flags": "0x0531",
      "mapped_to": "0x0053",
      "mapping_flags": "0x0000"
    },
    {
      "index": 4,
      "cid": "0x0056",
      "task": "0x003E",
      "flags": "0x0531",
      "mapped_to": "0x0056",
      "mapping_flags": "0x0000"
    },
    {
      "index": 5,
      "cid": "0x00C3",
      "task": "0x009C",
      "flags": "0x0531",
      "mapped_to": "0x00C3",
      "mapping_flags": "0x0000"
    },
    {
      "index": 6,
      "cid": "0x00C4",
      "task": "0x009D",
      "flags": "0x0531",
      "mapped_to": "0x00C4",
      "mapping_flags": "0x0000"
    },
    {
      "index": 7,
      "cid": "0x01A0",
      "task": "0x0109",
      "flags": "0x0531",
      "mapped_to": "0x01A0",
      "mapping_flags": "0x0000"
    },
    {
      "index": 8,
      "cid": "0x00D7",
      "task": "0x00B4",
      "flags": "0x03A0",
      "mapped_to": "0x00D7",
      "mapping_flags": "0x0000"
    }
  ],
  "gesture_candidates": [
    "0x00C3",
    "0x00D7"
  ]
}

Log file contents

Screenshots or screen recordings

No response

Additional context

No response

[KhalidWar]

I'm looking to ditch Logi Options app for this exact same reason. Is Mouser always like this?

[Stelath]

I've been thinking of doing a rewrite in rust or C++ so it would basically use nothing, is there enough interest? Also I'm not opposed to contributing that to mouser but only if the owner of the repo is ok with replacing the entire repo structure basically. Otherwise might just make a fork as its MIT licensed.

[boralp]

@Stelath I don’t think this is mainly a “Python is slow” issue. It looks more like a producer/consumer burst mismatch problem.

OS/device callbacks can arrive in bursts (scroll, gestures, reconnects, callback clumps after stalls), while the worker processes them serially. Even if average rates are low, temporary stalls can create backlog growth, and with an unbounded queue memory can grow indefinitely over long runtimes.

So the bounded queue is more of a safety/backpressure mechanism than a pure performance optimization. For input systems, freshness matters more than replaying stale events later, which is why dropping older events under overload is usually the correct tradeoff.

This is my (PR)[https://github.com//pull/151]

[Stelath]

@boralp Agreed that this looks like just a memory leak; I'll take a look at your PR. But still I don't like the fact that it has to bundle and run the whole python interpreter for whats essentially a glorified mouse driver (don't get me wrong I still love this project). He's already using QT for the GUI so to me it kind of makes sense to just move everything over to C++ instead of tech debiting too far into python. Not trying to be the "python bad" "c++ and rust good" guy but in this case for a driver its my personal opinion that they should all be written to take as little memory as possible (something Logitech's own software doesn't do I might add lol, which is partially why it infuriates me).

[boralp]

@Stelath I’d really like to be on the same page here in theory.

My concern is more about project momentum right now. There’s a lot of activity, people reporting issues, fixes landing, and improvements happening quickly. A major language/runtime migration would be a huge engineering effort and could easily stall that momentum, which is probably more damaging than the current footprint issues.

You may also like how libusb approaches some of this:
https://github.com/libusb/libusb