Does pug's built‑in view cache save enough CPU time to warrant its unbounded memory growth in low‑traffic Node apps?

Goal

Determine whether enabling Pug's built‑in template cache yields a measurable per‑request latency reduction that justifies allowing the cache to grow without bounds in a low‑traffic Node.js application that may render many distinct templates over time.

Constraints and uncertainty

• The application serves low traffic, so per‑request CPU savings are small, but memory usage can accumulate if each distinct template is cached indefinitely.
• Pug’s cache has no automatic eviction, size limit, TTL, or file‑watching mechanism, and its behavior differs across major versions (compileDebug, pretty defaults).
• In clustered or serverless deployments each worker maintains its own cache, affecting overall memory footprint.
• The actual trade‑off depends on the exact installed Pug version, the number of unique templates rendered per hour, and the acceptable memory budget.

Questions

• Does enabling the view cache produce a net latency improvement that outweighs the memory growth for a workload rendering X distinct templates per hour?
• What practical approaches can bound the Pug template cache size or introduce a TTL without altering the Pug library itself?
• How does the per‑worker cache behave in a clustered or serverless environment, and does it change the cost‑benefit analysis?