# One Map Key, One Lookup

DevFeed: [One Map Key, One Lookup](<https://devfeed.tech/articles/one-map-key-one-lookup-23868.md>)

Original publisher: [Read original article](<http://testing.googleblog.com/2026/04/one-map-key-one-lookup.html>)

Author: Google Testing Bloggers (noreply@blogger.com)

Published: 2026-04-29T12:26:00Z

Content type: tutorial

Language: en

Sources: [Google Testing Blog](<https://devfeed.tech/sources/google-testing-blog.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>), [Java](<https://devfeed.tech/topics/java.md>), [container](<https://devfeed.tech/topics/container.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [code](<https://devfeed.tech/tags/code.md>), [container](<https://devfeed.tech/tags/container.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [go](<https://devfeed.tech/tags/go.md>), [java](<https://devfeed.tech/tags/java.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [roman-govsheev](<https://devfeed.tech/tags/roman-govsheev.md>), [tech](<https://devfeed.tech/tags/tech.md>), [tott](<https://devfeed.tech/tags/tott.md>)

## AI overview

This Google Tech on the Toilet article explains how checking for a map key and then fetching its value performs redundant work. It recommends retrieving the value once and reusing it, with corresponding idioms in Python, Go, C++, and Java, and discusses avoiding similar check-then-act patterns when counting or initializing values.

## Source excerpt

This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Roman Govsheev Can you spot the wasted CPU cycles in the map usage? if employee_id in employees: mail_to(employees[employee_id].email_address) The redundant lookup caused the waste by performing a check (in) and a fetch ([]) as two separate operations when one is sufficient. Every lookup involves a cost--whether it's computing a hash and scanning buckets or performing an O(log n) traversal. These costs add up quickly. But avoiding them isn't just "premature optimization"--it's about writing cleaner, more robust code that stays efficient at scale and prevents potential race conditions. Instead of paying this cost twice, perform the lookup once and reuse the result: if (employee := employees.get(employee_id)) is not None: mail_to(employee.email_address) Assigning the search result to a variable avoids a second lookup. This efficiency is native to Go via the "comma ok" idiom (val, ok := map[key]) and C++ using map.find(key), both handling retrieval and existence in a single pass. The same inefficiency applies when counting or initializing default. Stop checking for presence; instead, use idioms that handle missing keys automatically at the container level: The redundant way The efficient way If key not in counts: counts[key] = 1 else: counts[key] += 1 counts = defaultdict(int) # Initializes 0 automatically # ... other logic ... counts[key] += 1 Here are some details depending on which language you use: C++: operator[] returns a reference to the value--automatically inserting a default (like 0) if the key is missing--allowing the increment to happen in place. Java: Use map.computeIfAbsent() to perform retrieval and updates in a single call. This is more concise and, on concurrent collections, has the potential to be thread-safe--preventing the "check-then-act" race conditions common with separate contains an