https://dailypypy.org/tags/latency/ Recent content in Latency on 每日拍拍 Hugo -- gohugo.io zh-tw © 2026 每日拍拍 Wed, 30 Sep 2026 10:41:00 +0800 155076163427069952 154825760438254592 https://dailypypy.org/learn/streamlit-performance-profiling/ Wed, 30 Sep 2026 10:41:00 +0800 https://dailypypy.org/learn/streamlit-performance-profiling/ <!--- 1440x768 prompt: masterpiece, best quality, highres, clean anime illustration, japanese anime style, soft shading, flat color design, 1girl, black hair, green eyes, white off-shoulder shirt, black short skirt, from above, three-quarter view, crouching beside three translucent blank gauge panels while tracing a soft glowing line with one finger, alert analytical smile, looking up at viewer, pastel aqua and pale lilac background, subtle stopwatch circles and memory-block shapes without symbols, logos, markings, numbers, letters, or text, neat composition, detailed eyes, cute and smart vibe, minimal background, polished illustration, no text negative prompt: worst quality, bad eye, bad hand, extra limbs, manga, multiple views, monochrome, text, signature dedup note: This is a measurement-specific follow-up to ../python-streamlit-advanced/, ../streamlit-fragments-dialogs/, ../streamlit-apptest-pytest/, and ../python-profiling/. Those articles teach cache and Session State usage, fragment rerun boundaries, functional AppTest checks, or general cProfile/line_profiler. This article instead defines Streamlit latency budgets, instruments complete reruns and app stages, runs controlled cold/warm cache experiments, tracks RSS versus Python heap, and turns AppTest timings into regression evidence. source check: Reviewed against the current official Streamlit execution-flow, st.cache_data, st.cache_resource, and AppTest documentation on 2026-09-30. The examples use public APIs and treat AppTest as server-side regression evidence, not browser end-to-end latency. ---> <p> <figure> <img class="my-0 rounded-md" loading="lazy" alt="featured" src="./featured.png" /> </figure> </p> <p>Streamlit App 變慢時，最危險的一句話是：「應該是圖表太多吧。」</p> <p>也可能是每次 widget 互動都重讀檔案、cache key 不斷改變、某個 API 偶爾卡住，或同一份 DataFrame 被複製到記憶體好幾次。</p> <p>如果沒有量測，優化就只是在猜。</p> <p>這篇拍拍君不再重教 <code>st.cache_data</code> 怎麼寫，也不把一般 Python profiler 全搬過來。我們要建立一套 Streamlit 專用的診斷流程：</p> <ol> <li>先定義冷啟動與暖 rerun 的 latency budget；</li> <li>量測整輪 rerun，以及 load、transform、render 各階段；</li> <li>用受控實驗分辨 cache hit、miss 與 key 爆炸；</li> <li>同時觀察 RSS 和 Python heap，不被單一數字騙走；</li> <li>用 AppTest 留下可重複比較的 server-side benchmark。</li> </ol> <p>如果你想先補 Streamlit 的 rerun 與 cache 基礎，請看 <a href="../python-streamlit-advanced/">Streamlit 進階篇</a>；想縮小 rerun 範圍，則接著看 <a href="../streamlit-fragments-dialogs/">Fragments + Dialogs</a>。</p>