Discard Your Big O Cheat Cards and Understand Them Instead!

By Fuat Can Koseoglu, 2025-10-20

Maybe you have seen study cards with a question on the front and the answer on the back. They repeat the same list: arrays read in O(1), hash tables search in O(1), balanced trees take O(log n), and priority queues stay near O(log n). That list is handy, but it does not help when you meet a new problem. You need to know what is happening under the hood. Think about an array first. Every value sits next to the next one in memory. The CPU adds the index to the starting place and reads the value at once, so random reads feel instant. Ask the array to add something at the front and every value must move one step. The cost is not magic; it is copying many items in order. Now picture a hash table. The hash function picks a bucket, and in a healthy table that bucket holds only a few items. If too many keys land together, you still find the answer but you walk through more items and slow down. The O(1) promise survives only when resizing keeps those buckets small. Balanced binary trees use another trick. Each comparison drops half of the remaining branch because rotations keep the height even. Skip rebalancing and the tree stretches tall, so the log n advantage disappears. The number counts the steps from root to leaf. Heaps, which power many priority queues, have their own rhythm. The smallest or largest item lives at the top. Inserts climb up, removals fall down, and both paths stay short. That is why each operation takes only a few swaps even in large heaps, and why peek is cheap. When you see Big O on a chart, focus on the real work the CPU does. Ask yourself what must move, how often the code compares, and how many pointers change. With that habit you do not have to memorize every table. You can reason about familiar collections and new ones too. Key insight: when you map every Big O label to the real CPU moves behind it, you can predict performance without a cheat sheet. Follow for O(1) daily game-dev tips!