Choosing @CompileStatic over dynamic dispatch for low‑traffic Groovy services: memory vs flexibility trade‑off

We need to lower JVM heap and per‑request CPU for a Groovy service that receives only a few requests per hour and runs in a memory‑constrained container.

The default dynamic dispatch routes every call through MetaClass objects and call‑site caches, adding overhead that is not amortised by JIT on such sparse traffic. Applying @CompileStatic replaces those call sites with direct static invocations, reducing heap pressure and CPU, but it disables runtime metaprogramming (categories, expandos, method injection) that some libraries or DSLs rely on. The alternative indy distribution uses invokedynamic bytecode, yet its benefit varies by JVM vendor and does not guarantee lower resource use for cold‑start, low‑traffic workloads.

• Does @CompileStatic consistently reduce retained heap and CPU time per request in a cold‑start, low‑traffic scenario?
• Can the indy backend achieve comparable savings without sacrificing dynamic features?
• Which profiling method (e.g., JFR, async‑profiler) best isolates MetaClass dispatch overhead versus static call cost?