IDriver.GetMemoryFootprint / FlushOptionalCachesAsync have no consumer after #522 #525

New Issue

2026-07-30T04:56:41-04:00

dohertj2 commented

2026-07-30 04:56:41 -04:00

Split out of #522, which deleted the driver-tier recycle machinery. Kept separate on purpose: removing these touches all 12 drivers and every test stub, which would have buried the reviewable part of that change in mechanical churn.

What is true today

IDriver.GetMemoryFootprint() and IDriver.FlushOptionalCachesAsync() have no production call site. Their only consumer was MemoryTracking, deleted in #522.
Outside the driver implementations themselves, the only references are the interface declarations and the stub IDriver inside DriverHostActor (=> 0 / Task.CompletedTask).
GetMemoryFootprint's doc-comment previously claimed "Polled every 30s by Core", which was not true in v3 even before #522 — nothing polled it. Both members now carry a doc-comment stating they are unconsumed.
All 12 drivers still implement them; several compute a real number (symbol-table and cache sizes), which is now wasted work on some paths, though cheap.

The decision

(a) Delete both from IDriver. Removes ~12 implementations plus test stubs. Purely mechanical, but wide — best done alone, not alongside a behavioural change.

(b) Keep and build a consumer. If per-driver memory pressure is wanted again, build it for the architecture as it now is: a process-wide watchdog that can ask individual drivers to flush caches — not a per-driver tier whose only remedy needed an out-of-process supervisor that cannot exist in-process (see #522 for why that model is gone). FlushOptionalCachesAsync is the genuinely useful half here — it degrades gracefully, where recycle did not — and the drivers' existing implementations would be reusable as-is.

Unlike #522, there is a real argument for (b): a long-running server with symbol-cache-heavy drivers (TwinCAT, AB CIP) does benefit from a flush-under-pressure path, and the driver-side work is already written. What is missing is only the trigger.

Split out of #522, which deleted the driver-tier recycle machinery. Kept separate on purpose: removing these touches **all 12 drivers and every test stub**, which would have buried the reviewable part of that change in mechanical churn. ## What is true today - `IDriver.GetMemoryFootprint()` and `IDriver.FlushOptionalCachesAsync()` have **no production call site**. Their only consumer was `MemoryTracking`, deleted in #522. - Outside the driver implementations themselves, the only references are the interface declarations and the stub `IDriver` inside `DriverHostActor` (`=> 0` / `Task.CompletedTask`). - `GetMemoryFootprint`'s doc-comment previously claimed *"Polled every 30s by Core"*, which was **not true in v3** even before #522 — nothing polled it. Both members now carry a doc-comment stating they are unconsumed. - All 12 drivers still implement them; several compute a real number (symbol-table and cache sizes), which is now wasted work on some paths, though cheap. ## The decision **(a) Delete both from `IDriver`.** Removes ~12 implementations plus test stubs. Purely mechanical, but wide — best done alone, not alongside a behavioural change. **(b) Keep and build a consumer.** If per-driver memory pressure is wanted again, build it for the architecture as it now is: a **process-wide watchdog** that can ask individual drivers to flush caches — *not* a per-driver tier whose only remedy needed an out-of-process supervisor that cannot exist in-process (see #522 for why that model is gone). `FlushOptionalCachesAsync` is the genuinely useful half here — it degrades gracefully, where recycle did not — and the drivers' existing implementations would be reusable as-is. Unlike #522, there is a real argument for (b): a long-running server with symbol-cache-heavy drivers (TwinCAT, AB CIP) does benefit from a flush-under-pressure path, and the driver-side work is already written. What is missing is only the trigger.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#525