編輯：快速注意，這幾乎肯定會混淆Big O符號（這是一個上限）與Theta符號（這是一個上限和下限）。根據我的經驗，這實際上是非學術環境中的典型討論。對所引起的任何混亂道歉。

用一句話：隨著工作規模的增加，完成工作需要多長時間？

顯然，只使用“大小”作為輸入，“時間”作為輸出 - 如果你想談論內存使用等，同樣的想法也適用。

這是一個我們想要干燥的N T恤的例子。我們假設讓它們處于干燥位置非?？欤慈祟惖南嗷プ饔每梢院雎圆挥嫞，F實情況并非如此，當然......

• 在外面使用清洗線：假設你有一個無限大的后院，洗滌在O（1）時間內干燥。無論你有多少，它都會得到相同的陽光和新鮮空氣，因此尺寸不會影響干燥時間。

• 使用滾筒式烘干機：每次裝入10件襯衫，然后一小時后完成。（忽略這里的實際數字 - 它們是無關緊要的。）因此，干燥50件襯衫所需的時間約為干燥10件襯衫的5倍。

• 把所有東西都放在一個通風櫥里：如果我們將所有東西放在一個大堆中，只是讓一般的溫暖去做，那么中間襯衫需要很長時間才能變干。我不想猜測細節，但我懷疑這至少是O（N ^ 2） - 隨著你增加洗滌負荷，干燥時間增加得更快。

“大O”符號的一個重要方面是它沒有說明給定大小的哪種算法會更快。獲取哈希表（字符串鍵，整數值）與對數組（字符串，整數）?；谧址诠１砘驍到M中的元素中查找鍵是否更快？（即對于數組，“找到字符串部分與給定鍵匹配的第一個元素。”）哈希表通常是攤銷的（?=“平均”）O（1） - 一旦它們被設置，它應該采取同時在100條目表中查找條目，如1,000,000條目表中所示。在數組中查找元素（基于內容而不是索引）是線性的，即O（N） - 平均而言，您將不得不查看一半的條目。

這是否使哈希表比查找數組更快？不必要。如果你有一個非常小的條目集合，一個數組可能會更快 - 你可以在計算你正在查看的哈希碼的時間內檢查所有字符串。然而，隨著數據集變大，哈希表最終會擊敗數組。