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

Short answer

In a typical low‑traffic Node.js application, enabling Pug’s view cache gives a tiny CPU‑latency benefit that is usually outweighed by the linear memory growth of caching every distinct template. Turn the cache on only if you render dozens of unique templates per hour and your memory budget is generous; otherwise, keep it off or add a manual eviction layer.

Why the cache matters

• Pug compiles a template into a JavaScript function the first time it is rendered.
• Subsequent renders reuse that function, avoiding the compile step.
• The compile step is a one‑time cost; per‑request CPU savings are a few microseconds to a few milliseconds, depending on template size.

CPU vs memory trade‑off

Typical metrics (Node 18, Pug 3.x, 50 requests/min):

• Compile cost: 0.5–2 ms per new template.
• Per‑render latency saved: ~0.3–1 ms.
• Memory per cached function: 4–12 kB.
• After 200 distinct templates, memory ≈ 800 kB–2 MB.

For a serverless function with a 256 MB limit, a 2‑MB cache is negligible; for a 512 MB instance running many workers, the same cache multiplies per worker, potentially consuming dozens of megabytes.

When to enable

1. Low request rate (< 100 req/min) and few templates: Disable the cache; the compile cost is trivial and memory savings are real.
2. High template churn (hundreds per hour): Enable the cache; the aggregate compile time can become a noticeable fraction of total latency.
3. Memory‑constrained environments (serverless, containers with tight limits): Keep the cache disabled or bound.

Bounding the cache

Pug itself offers no eviction policy, but you can wrap the cache in a simple LRU or TTL mechanism:

const pug = require('pug');
const LRU = require('lru-cache');
const templateCache = new LRU({ max: 100, maxAge: 60 * 60 * 1000 }); // 100 templates, 1 h TTL

pug.renderFile = function (path, locals) {
  const key = path;
  let fn = templateCache.get(key);
  if (!fn) {
    fn = pug.compileFile(path, { compileDebug: false });
    templateCache.set(key, fn);
  }
  return fn(locals);
};

Alternatively, use environment variables to toggle caching and set a hard limit in your deployment configuration.

Cluster / serverless implications

• Each worker process has its own cache; memory usage multiplies by the number of workers.
• In serverless, each invocation may start a fresh process, so the cache does not persist across invocations unless you use a global shared store (e.g., Redis).
• Consider disabling the cache in the serverless runtime and relying on a pre‑compiled bundle if possible.

Diagnostic detail needed

The recommendation hinges on how many distinct templates your app renders per hour. If you can provide that number, we can refine the threshold for enabling or bounding the cache.