Persistent runner / server mode to eliminate per-invocation CLI startup overhead

[devJamStudio]

Problem

Every swamp workflow run or swamp model method run call incurs ~80s of fixed startup overhead (swamp framework init, workflow evaluation, vault resolution, Deno process startup). The actual execution inside the Deno model is fast — e.g. processing 4 tachograph .DDD files takes 276ms of real work but 82,858ms wall time end-to-end.

This makes swamp unusable for any workload that needs to process many items over time (file ingestion pipelines, webhook handlers, scheduled batch jobs) unless all work is batched into a single monolithic method call.

Proposed Solution

A persistent runner mode that keeps the swamp runtime alive and accepts workflow/model execution requests without restarting:

# Start a persistent runner
swamp runner start --port 8080

# Submit work to the running instance (fast, no startup cost)
swamp runner run tachograph-batch-activities --input '{"dirPath": "/data/ddd"}'

Expected Impact

• Per-request latency: ~82s → ~300ms (275x improvement)
• Enables real-time processing pipelines via swamp
• Vault secrets loaded once at startup, not re-resolved per call
• Deno runtime and extension models stay warm

Alternatives Considered

1. Batch everything into one method call — works but forces unnatural model design, bypasses per-file resource tracking
2. Standalone Deno HTTP server — fast but exits the swamp ecosystem entirely (no resource writes, no workflow history, no vault)
3. Accept the overhead — only viable for infrequent one-shot runs

Environment

• swamp: 20260226.140557.0
• OS: macOS (darwin 23.6.0, aarch64)
• Use case: EU tachograph .DDD file processing pipeline

[github-actions]

Hi @devJamStudio, thanks for opening this issue!

We appreciate you taking the time to report it. A maintainer will review it as soon as possible.

In the meantime, please make sure you've included all relevant details (steps to reproduce, expected vs actual behaviour, swamp version, etc.) to help us triage it quickly.

[stack72]

Thanks for the detailed report @devJamStudio — the 82s wall time for 276ms of actual work is clearly not right, and we want to dig into what's causing the overhead. A persistent runner/server mode is certainly on our roadmap, but we want to fix any issues that are immediately in the way here.

We've done some initial analysis of the startup path and identified several areas where time is likely being spent:

1. Extension model bundling — every user model file gets bundled via a deno bundle subprocess call, and these run sequentially. If you have many extension models, this alone could account for 20-60s.
2. Eager loading — models, vaults, and drivers are all loaded before your command starts, even if the command only needs a subset of them.
3. Vault initialization — all configured vault providers are initialized at startup, which may include network calls to external services (AWS Secrets Manager, etc.).

Before we design a fix, it would help to understand your setup better:

• How many extension models do you have in extensions/models/?
• How many vaults are configured? Are any of them remote (e.g. AWS Secrets Manager)?
• Does the first run after a swamp upgrade feel slower than subsequent runs? (This would point to Deno binary extraction or cache invalidation.)
• Could you run a single swamp model method run with --log-level debug and share the output (redacting any secrets)? The timestamps in the debug logs would help us pinpoint exactly where the time goes.

Has this changed lately or has it consistently been like this? What version of swamp CLI (swamp version) are you running?

[stack72]

Hey @devJamStudio — following up here. We shipped some fixes today that may well address the overhead you were seeing.

In latest stable version of the CLI:

• PR fix: skip extension loading for help/version commands, parallelize loaders (#738) #741 — parallelised all 4 extension loaders (previously sequential, each independently re-reading disk and re-instantiating the Deno runtime).
• PR perf: defer self-contained bundle creation to first out-of-process execution #743 — deferred self-contained bundle creation to the first actual out-of-process execution, rather than eagerly bundling every model on every invocation. We measured 104 extension models going from ~46s → ~2.8s startup.

Your ~80s overhead was almost certainly dominated by the eager-bundling path we fixed in #743.

Could you upgrade and re-run your benchmark? If you're still seeing significant overhead after upgrading, please share the debug output we asked for above and we'll dig in further.