agent-zero/docs/agents/office-tunnel-memory-note.md
Alessandro 2d389af727
Some checks failed
Build And Publish Docker Images / plan (push) Has been cancelled
Build And Publish Docker Images / build (push) Has been cancelled
Defer Office desktop startup
Make the Office canvas mount passive so Xpra starts only when the Desktop surface is opened or an official Office document is created/opened.

Track Desktop host visibility to unload hidden frames, stop monitors, dedupe viewport resize work, and set Xpra offscreen mode according to HTTPS support. Add a near-future note for the tunnel memory footprint.

Show Office desktop startup progress

Display a loading message while the Agent Zero Desktop environment is starting or restarting, so the right-canvas Desktop button gives immediate feedback before Xpra finishes waking up.
2026-05-03 03:26:04 +02:00

1.3 KiB

Office Tunnel Memory Footprint Note

During the ARM Desktop audit on 2026-05-03, run_tunnel.py was the clearest near-future memory optimization candidate. The process held roughly 573 MiB PSS while the main UI process held roughly 706 MiB PSS, even though the tunnel should mostly be a lightweight network edge.

Observed Shape

  • run_tunnel.py imports enough of the framework stack to pull in heavy provider and API dependencies.
  • The tunnel stays resident for the life of the container, so every eagerly imported module becomes steady-state memory.
  • The Desktop/Xpra service itself was not the largest outlier; the always-on tunnel process was.

Future Work

  • Split tunnel startup into a small import surface that only loads routing, auth, and socket plumbing required for health and proxy operation.
  • Lazy-import provider/framework modules only when a tunnel request truly needs them.
  • Review any ApiHandler or helper imports used by the tunnel path and replace broad framework imports with narrower functions.
  • Measure with smem -P run_tunnel.py, /proc/<pid>/smaps_rollup, and before/after cold-start RSS/PSS on ARM64.

Success Signal

The tunnel process should remain useful as an always-on edge while dropping its idle PSS substantially below the main UI process. A good first target is under 250 MiB PSS on ARM64 without changing tunnel behavior.