ReLibreHardwareMonitor/docs/optimization-plan.md

There doesn’t appear to be a test suite around Computer.Open() in the workspace, so the plan needs to add instrumentation and regression checks before changing scheduling. I’m going to summarize a conservative path: measure first, make UI progressively populated, then parallelize only independent groups with explicit resource classes.

• Updated Plan └ ✔ Trace current hardware initialization path ✔ Identify blocking and serial discovery hotspots □ Present prioritized optimization plan

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── • Findings Computer.Open() is fully serial today: SMBIOS, mutex setup, OpCode.Open(), then every enabled group in fixed order. Expensive candidates include motherboard LPC/EC/ IPMI, memory SPD driver/SMBus probing, GPU vendor APIs, storage enumeration, network enumeration, USB/serial controller scans, PSUs, power monitors, and battery device IO.

Some groups are independent, but not all are safe to parallelize blindly. ISA/PCI/EC/USB sensor paths use shared mutexes and some constructors perform fixed sleeps or driver/native calls.

Plan

1. Add startup timing instrumentation first. Record per phase: SMBIOS, OpCode.Open, each IGroup constructor, hardware count, exceptions, and elapsed time. Put this behind a debug/log setting so we can compare before/after without guessing.

2. Improve perceived startup in WinUI. Show the shell immediately, then populate groups as they complete. Status should say which group is initializing. This preserves correctness and makes slow probes visible instead of looking hung.

3. Split Computer.Open() into staged group discovery. Keep required global setup serial: SMBios, Mutexes.Open, OpCode.Open. Then schedule group creation through a small initialization coordinator.

4. Parallelize only low-conflict groups first. Good first candidates: CpuGroup, NetworkGroup, BatteryGroup, StorageGroup, AMD/NVIDIA GPU groups, non-dependent PSU groups.

5. Add dependency/resource classes. Use explicit buckets such as Cpu, GpuVendorApi, Storage, Network, Battery, IsaBus, PciBus, Ec, UsbHid, SerialUsb. Groups in the same risky bucket stay serialized; independent buckets can run concurrently. Controller groups contain some worst-case sleeps and USB/serial scans. Load them after core CPU/GPU/motherboard/storage sensors, or expose “defer fan/controller detection” while still defaulting to correctness. HardwareAdded should fire as each group completes. Computer.Hardware needs lock-safe snapshots so UI and web server can read while discovery continues.

6. Regression checks. Compare before/after reports and sensor identifiers on the same machine. The correctness bar should be: same enabled hardware groups eventually discovered, same sensor identifiers where hardware is present, no lost late-added memory/GPU devices.

Recommended implementation order:

1. Timing instrumentation.
2. Progressive WinUI population/status.
3. Async Computer.OpenAsync with serial behavior.
4. Parallelize low-conflict groups.
5. Defer/lazy heavy controller probes.
6. Broaden with resource-bucket scheduling after logs prove hotspots.