perf: serial device discovery is too slow — probes ports sequentially with excessive commands and timeouts

[cptkoolbeenz]

Description

Serial device auto-discovery takes ~1 minute+ on systems with many COM ports (Bluetooth, virtual ports, etc.). Each port is probed sequentially and the per-port probe takes ~5.4 seconds to timeout on non-DAQiFi ports, making the experience feel broken.

The desktop app's USB tab shows an indefinite spinner until discovery completes, so users think it's not working and fall back to manual COM port entry.

More importantly, the current approach opens and sends commands to every COM port on the system, including ports belonging to other devices. We should not be probing ports that aren't ours.

Current Probe Behavior

In SerialDeviceFinder.TryGetDeviceInfoAsync(), each port goes through:

1. Open port at 9600 baud
2. Enable DTR
3. 1000ms wake-up delay (DeviceWakeUpDelayMs)
4. Send DisableDeviceEcho + 100ms delay
5. Send StopStreaming + 100ms delay
6. Send TurnDeviceOn + 100ms delay
7. Send SetProtobufStreamFormat + 100ms delay
8. Send GetDeviceInfo up to 3 times with 1000ms retry intervals
9. 4000ms total response timeout (ResponseTimeoutMs)

Total worst case per port: ~5.4 seconds

With 10+ COM ports on a typical Windows system, this easily exceeds 1 minute.

Problems

1. No port filtering by USB descriptor — probes devices that aren't ours

All COM ports are probed regardless of their USB Vendor/Product ID. This means we're opening ports and sending SCPI commands to other vendors' devices (Bluetooth radios, GPS receivers, Arduinos, etc.). DAQiFi devices have known VID/PID values — we should only probe ports that match. This is the highest priority fix because it's both a correctness issue (don't talk to other devices) and a performance issue (skip non-DAQiFi ports entirely).

2. Too many commands before the probe

The probe sends 4 commands (DisableEcho, StopStreaming, TurnDeviceOn, SetProtobufStreamFormat) before GetDeviceInfo. For a simple identity check, only GetDeviceInfo (SYSTem:SYSInfoPB?) should be needed — the device doesn't need to be powered on or have streaming stopped just to respond to an info query.

3. Excessive timeouts for USB

USB serial communication is near-instant. The current timeouts (1s wake-up, 4s response, 1s retry interval) are designed for worst-case scenarios but are far too conservative for a discovery probe. A DAQiFi device on USB should respond to SYSTem:SYSInfoPB? within a few hundred milliseconds.

4. Sequential probing

Ports are probed one at a time. Non-DAQiFi ports must fully timeout before the next port is tried.

Suggested Improvements (in priority order)

1. Filter by USB VID/PID first (highest priority)

Use WMI or Windows Setup API to identify COM ports by their USB Vendor/Product ID before opening any ports. Only probe ports matching known DAQiFi VID/PID values. This eliminates the problem of sending commands to other vendors' devices and skips the vast majority of ports on the system instantly — no timeouts, no SCPI commands, no port opens needed for non-DAQiFi hardware.

2. Reduce probe to minimum commands

Just send GetDeviceInfo (SYSTem:SYSInfoPB?) — skip DisableEcho, StopStreaming, TurnDeviceOn, SetProtobufStreamFormat. These are connection setup commands, not needed for a discovery probe.

3. Shorten timeouts

Wake-up delay 200ms (or remove entirely), response timeout 1000ms, retry interval 300ms. USB is fast. Reduce retries to 1-2 attempts instead of 3.

4. Probe remaining ports in parallel

If multiple DAQiFi VID/PID ports exist, probe them simultaneously with Task.WhenAll.

Expected Improvement

With VID/PID filtering alone, discovery should drop from ~1 minute to <1 second on most systems, since only actual DAQiFi ports would be probed. Combined with minimal commands and shorter timeouts, the per-port probe would take ~200-500ms instead of ~5.4s.

🤖 Generated with Claude Code