st.cache_data vs st.experimental_memo: Choosing the Right Decorator for Repeatable Data Loading
0 reputation · 29 Dec 2020, 14:00 UTC
0 reputation · 29 Dec 2020, 14:00 UTC
We want a development environment where loading a CSV file via a Streamlit decorator yields the same cached result across script restarts until the file changes.
The project uses Streamlit 1.18 or newer, so both st.cache_data (stable) and st.experimental_memo (legacy) are available. The cache must survive a full app reload but be invalidated when the underlying data file changes.
While st.cache_data is documented to separate data caching from resource caching, st.experimental_memo may over‑cache heavy objects and can change behavior with Streamlit upgrades. Additionally, handling of unhashable inputs (e.g., DataFrames with mutable indexes) differs between the two decorators.
st.cache_data guarantee that identical inputs produce identical cached outputs across script restarts, whereas st.experimental_memo may invalidate unexpectedly?st.experimental_memo compared to the stable st.cache_data API?34775 reputation · 29 Dec 2020, 20:34 UTC
Use @st.cache_data. In Streamlit 1.18+ it is the stable API for data loading and it is the documented replacement for st.experimental_memo. Both decorators will return the same cached result across script restarts when the inputs are identical, but st.cache_data gives you a stable contract and a serialized copy of the return value. st.experimental_memo is legacy and is subject to removal or behavior changes in future releases.
st.cache_data is the stable replacement for st.experimental_memo and is recommended for data-loading tasks.st.cache_data stores a serialized copy of the return value, so mutations to the returned object do not affect the cached value.st.experimental_memo was the precursor to st.cache_data; in 1.18+ it is functionally redundant and considered legacy.Likely: st.experimental_memo may invalidate unexpectedly after upgrades because its API is experimental. Confirmed: the stable API is st.cache_data. Handling of unhashable inputs is similar for both: Streamlit attempts to hash arguments. Passing large unhashable objects like a DataFrame with a mutable index as an argument can trigger hashing errors or high overhead. The recommended pattern is to avoid passing unhashable objects as cache keys and instead pass hashable proxies such as path strings and timestamps.
@st.cache_data. Do not use st.experimental_memo for new code.os.path.getmtime(path) or a content hash.import os
import pandas as pd
import streamlit as st
@st.cache_data
def load_csv(path: str, mtime: float):
return pd.read_csv(path)
path = "data.csv"
mtime = os.path.getmtime(path)
df = load_csv(path, mtime)
With this pattern the cache survives a full app reload and is invalidated only when mtime changes.
st.cache_data is stable. st.experimental_memo is subject to removal or behavior changes in newer Streamlit releases. Migrating now avoids breaking changes later.
Assumption: Streamlit 1.18 or newer, default on-disk cache enabled. If you are running with a non-persistent cache directory or an older patch, verify cache persistence in your deployment.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 30 Dec 2020, 00:04 UTC
One clarification worth adding: st.experimental_memo is not a separate caching strategy from st.cache_data—it is the direct experimental predecessor with the same data-caching semantics. The data/resource split actually lives between st.cache_data and st.cache_resource (formerly st.experimental_singleton), not between st.cache_data and st.experimental_memo.
Regarding persistence, neither decorator survives a browser reload or server restart by default in standard in-memory mode; both are session-scoped and require the version-sensitive persist parameter for disk-backed caching. For unhashable inputs, both accept hash_funcs, so a DataFrame with a mutable index can be handled identically under either decorator.
Because st.experimental_memo is legacy and may be removed in future Streamlit releases, migrating to st.cache_data is the safer upgrade path. Verify behavior against your installed version before relying on cross-restart guarantees.