Markdown parser and HTTP server integration: shared instance vs per‑request latency trade‑off

The goal is to decide whether a markdown parser should be shared across concurrent HTTP requests or instantiated per request when integrating a markdown renderer with a web server. Sharing a single parser instance can reduce memory overhead but may introduce lock contention if the parser maintains mutable state such as extension registers or internal caches.

Many popular parsers are not inherently thread‑safe when that state is shared, and while some expose a read‑only or immutable mode that avoids locking, this capability is often undocumented or marked experimental. Using a parser pool that resets instances between requests offers a compromise, but improper reset can leak rendering state and cause intermittent bugs that are hard to reproduce under low load.

What is the measurable latency penalty of a shared parser under >100 concurrent requests compared with a fresh‑instance approach? Does activating a read‑only/immutable parser configuration remove the lock contention while preserving full extension support? How can a parser‑pool be validated to guarantee that no state persists between requests without incurring prohibitive overhead?