Why Go 1.24’s New SwissMap Can Slow Down Large Maps—and How the Team Plans to Fix It

This article explains why in Go 1.24 your program may become slower because of map performance regressions, and how the Go team plans to address the issue.

Go’s map in the new version uses a Swiss Table implementation, which is extremely fast for small maps and high‑concurrency scenarios, but can become slower when the map is large and the data is "cold" (not residing in the CPU cache).

Where does the problem come from?

The internal structure of SwissMap is more complex and consists of several layers:

First, a map header structure.

It points to a directory, which is a list of pointers to multiple tables.

Each table contains control information, keys, and values.

When looking up a key, the algorithm may need 4 to 6 jumps, each potentially missing the cache, causing the CPU to fetch data from main memory and slowing down the operation.

Large projects such as Prometheus observed a noticeable increase in CPU usage after upgrading to Go 1.24, which was traced back to slower map lookups.

How was it discovered?

The issue was not found in synthetic tests but emerged in real‑world production workloads that use very large maps, perform frequent reads, and have data that does not stay in the CPU cache.

Go engineer Michael Pratt performed extensive testing and documented the cause in Issue #70835.

What is being done to fix it?

The Go team plans several changes to make maps faster again:

Simplify the directory structure : replace the pointer list with a direct‑structure layout to reduce one level of indirection.

Make control information more compact : arrange control data more tightly so the CPU can load it in a single cache line.

Separate key and value storage : adopt a "key‑key‑key + value‑value‑value" layout to improve loading order.

Align control bytes : align control information to cache boundaries to reduce cache misses.

These changes are non‑trivial because they affect the Go runtime core, requiring careful handling of garbage collection, map growth/shrink logic, and ensuring that performance for small maps is not degraded.

Where is the discussion?

The problem is tracked in Issue #70835 and is slated to be resolved in Go 1.25. A related memory‑layout discussion appears in Issue #71368.

Conclusion

The Go team continuously works to make the language faster and more stable. SwissMap is a valuable improvement, but it introduced new challenges such as cold‑cache performance degradation. Community feedback from projects like Prometheus helps drive these enhancements, and the upcoming Go 1.25 release aims to restore speed and stability.