當資料量變大時，程式執行時間的增長速度往往比硬體速度快更重要。時間複雜度用數學方式描述演算法執行時間如何隨輸入規模增長，是評估與選擇演算法的基本工具。
Big O 描述的是最壞情況下，執行步驟數隨輸入大小 n 增長的上界，忽略常數與低階項。它關注的是增長趨勢，而不是精確的執行時間。例如 O(n) 表示時間大致與 n 成正比，O(n²) 表示與 n 的平方成正比。
常見等級由快到慢大致為：
| 複雜度 | 名稱 | 典型例子 |
|---|---|---|
| O(1) | 常數 | 陣列以索引取值、雜湊表平均查找 |
| O(log n) | 對數 | 二元搜尋、平衡樹操作 |
| O(n) | 線性 | 遍歷陣列一次 |
| O(n log n) | 線性對數 | 效率良好的排序（合併、快速排序平均） |
| O(n²) | 平方 | 簡單嵌套迴圈、冒泡排序 |
| O(2ⁿ) | 指數 | 某些遞迴暴力搜尋 |
假設某操作在 n = 1,000 時可接受。若演算法是 O(n²)，當 n 變成 10,000 時，步驟數大約變成 100 倍；若是 O(2ⁿ)，則可能完全無法計算。選擇合適的演算法與資料結構，常常比微優化常數更有效。
空間複雜度同樣重要。有些演算法用額外記憶體換取時間，有些則相反。實際系統需要在兩者之間取捨。
分析時要看最壞情況，也要注意隱藏的成本（例如某些語言的字串串接在迴圈中可能是平方時間）。平均情況與最壞情況可能不同，雜湊表就是典型例子。
先寫正確、清晰的程式，再用測量工具找出真正的瓶頸。過早優化常常浪費時間。當資料規模會成長，或已觀察到效能問題時，再針對熱點分析複雜度並改進。使用標準程式庫的演算法通常已經過良好實作，優先重用而非自行撰寫。
理解複雜度也有助於閱讀技術文件與選擇資料庫索引、快取策略等。它是電腦科學的基礎語言之一。
程式練習與小工具可以幫助觀察不同輸入規模下的執行差異，但精確測量需要控制變因與多次執行。理論分析與實際測量應互相驗證。Wusper 的開發相關工具（編碼、雜湊、文字處理等）本身的實作也遵循合理複雜度，適合日常使用。