Latency limits of @st.cache_data under concurrent Streamlit requests

When using Streamlit’s @st.cache_data decorator, the first request for a given input triggers the underlying function, while subsequent requests reuse the stored result. In a concurrent setting, multiple sessions may attempt to evaluate the same uncached call at the same time. The framework protects against redundant work by serializing access, but it is unclear whether this serialization introduces measurable latency that appears only under load, and how that latency scales with the number of simultaneous requests.

Understanding whether the cache adds a constant overhead, a variable wait time proportional to concurrency, or negligible impact helps decide when to rely on caching for latency‑sensitive workloads. This is especially relevant for applications that expect bursty traffic and share expensive computations across users.

What latency behavior does @st.cache_data exhibit when two or more users request the same uncached value concurrently? Does the observed latency increase linearly with the number of concurrent requests, or does it remain constant after the first computation?