55 lines
3.5 KiB
Markdown
55 lines
3.5 KiB
Markdown
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.
|