That reasoning made sense at first glance, but it left me curious. I knew the theory, but I wanted to quantify the actual performance impact of not draining response bodies.

This post documents that investigation.

Source code of this experiment can be found in this GitHub repository.

Why This Matters

HTTP keep-alive and connection reuse are critical for performance in modern applications. If clients fail to properly consume responses, they can inadvertently disable connection pooling, forcing expensive new TCP (and potentially TLS) handshakes on each request.

This problem is subtle: your code may work fine in tests, but at scale, the performance degradation can be dramatic.

How Go’s HTTP Transport Works

When you issue a request with http.Client.Do(req):

1. The request is dispatched through the configured Transport (by default, http.Transport).
2. The transport either opens or reuses a TCP connection to the server.
3. The server replies with headers followed by a body (either length-delimited or chunked).
4. Go exposes the body as resp.Body, which is more than a simple io.ReadCloser. It manages the underlying connection and determines whether it can be reused.

Case 1: Closing Without Reading to EOF

If you call resp.Body.Close() before consuming all bytes:

• Unread bytes remain in the buffer. Suppose the server sends Content-Length: 1000, but you only read 100 bytes. The remaining 900 bytes still sit in the TCP buffer.

• Connection reuse becomes unsafe. The Transport cannot guarantee the connection is aligned with the next request boundary.

• The connection is discarded. Instead of returning the connection to the idle pool, Go closes it.

• Practical effect: The next request must open a fresh TCP (and TLS) connection, which increases latency and CPU load.

Case 2: Reading to EOF and Closing

If you fully consume the response body:

• The Transport can confirm the stream is aligned.
• Closing returns the connection to the idle pool.
• Subsequent requests reuse the same connection, avoiding extra handshakes.

Designing the Experiment

To measure the performance impact, I built a controlled test environment using only Go’s standard library and Docker for orchestration. The setup consisted of a simple HTTP client and server, plus infrastructure to collect and analyze metrics.

Server

The server responds to any request with a payload of configurable size. A path parameter controls the number of bytes to send back, which the server generates as random data. This allowed me to simulate different response sizes without external dependencies.

Client

The client was more involved. Key requirements:

• Protocol selection: Ability to enable only HTTP/1.1 or HTTP/2.
• Tracing: Integration with httptrace.ClientTrace to record connection and request lifecycle events.
• Configurable draining: Optionally read responses to EOF before closing.

Each client issues a “template” request n times in sequence, logging response times and tracing events. Configuration is done via environment variables.

Orchestration with Docker

The most complex part was orchestration. I used the Docker SDK to build images, manage networks, and control containers. While arguably over-engineered, the setup gave me fine-grained control over test runs.

The workflow:

1. Image and network setup

   • Compile client and server into separate binaries.
   • Build Docker images if missing.
   • Create a dedicated network for isolation.

2. Container creation

   • Six containers in total:

     • Four clients: HTTP/1.1 with/without draining, HTTP/2 with/without draining.
     • Two servers: one for draining clients, one for non-draining.

3. Data collection

   • Logs and metrics streamed via the Docker API.
   • Data stored in JSONL format for easy parsing.

4. Cleanup

   • Containers are removed after each run.

Running the Benchmark

Each client issued 10,000 sequential requests with the following command:

NUMBER_OF_REQUESTS=10000 go run ./cmd/bench/

To summarize results, I ran:

BENCH_RESULTS_DIRECTORY="benchresults/20250920155945" go run ./cmd/stats/

The stats tool computed min, max, mean, and median for response times and CPU usage. While I focused on latency and CPU, the dataset also allows analyzing connection reuse, memory usage, and error rates.

Results

The following is the output of the stats tool:

Summarizing result logs from file: benchresults/20250920155945/client-http-1-drain-0-logs.jsonl
Request Time:
- Min: 462.968µs
- Max: 4.002694458s
- Mean: 1.279138ms
- Median: 836.046µs

Summarizing result stats from file: benchresults/20250920155945/client-http-1-drain-0-stats.jsonl
CPU Usage:
- Min: 0.00%
- Max: 114.49%
- Mean: 72.64%
- Median: 108.39%

Summarizing result logs from file: benchresults/20250920155945/client-http-1-drain-1-logs.jsonl
Request Time:
- Min: 104.666µs
- Max: 4.01174869s
- Mean: 705.606µs
- Median: 285.943µs

Summarizing result stats from file: benchresults/20250920155945/client-http-1-drain-1-stats.jsonl
CPU Usage:
- Min: 0.00%
- Max: 89.40%
- Mean: 35.87%
- Median: 0.00%

Summarizing result logs from file: benchresults/20250920155945/client-http-2-drain-0-logs.jsonl
Request Time:
- Min: 452.761µs
- Max: 4.002149171s
- Mean: 1.273813ms
- Median: 829.245µs

Summarizing result stats from file: benchresults/20250920155945/client-http-2-drain-0-stats.jsonl
CPU Usage:
- Min: 0.00%
- Max: 113.48%
- Mean: 71.06%
- Median: 107.84%

Summarizing result logs from file: benchresults/20250920155945/client-http-2-drain-1-logs.jsonl
Request Time:
- Min: 105.359µs
- Max: 4.001713071s
- Mean: 707.408µs
- Median: 289.669µs

Summarizing result stats from file: benchresults/20250920155945/client-http-2-drain-1-stats.jsonl
CPU Usage:
- Min: 0.00%
- Max: 89.51%
- Mean: 34.10%
- Median: 0.00%

Summarizing result stats from file: benchresults/20250920155945/server-drain-0-stats.jsonl
CPU Usage:
- Min: 0.00%
- Max: 82.52%
- Mean: 51.61%
- Median: 79.07%

Summarizing result stats from file: benchresults/20250920155945/server-drain-1-stats.jsonl
CPU Usage:
- Min: 0.00%
- Max: 120.90%
- Mean: 27.23%
- Median: 0.00%

Highlights from the results:

• Draining improved mean request times by ~44.5% (both HTTP/1.1 and HTTP/2).
• Median latency improved by ~65% — the effect on typical requests is even stronger than on the average.
• Client CPU usage dropped by 50–52% when draining.
• Server CPU usage dropped by ~47% when clients drained responses.
• Without draining, both client and server CPUs often saturated near 100%; with draining, they frequently idled near 0%.

In other words, the cost of not draining is not just a small inefficiency—it can double CPU usage and dramatically increase latency.

Conclusion

Failing to drain HTTP response bodies in Go significantly harms performance for both clients and servers.

• Request latency: ~44.5% faster on average, ~65% faster at median.
• Client CPU: ~50% lower.
• Server CPU: ~47% lower.
• Connection reuse: Preserved with draining, disabled without it.

Practical Takeaway

Always drain the response body before closing, even when handling error responses you don’t care about. If you don’t need the content, discard it by reading to EOF and ignoring the bytes.

This small step ensures connection reuse, reduces CPU load, and dramatically improves performance—both for your client and the servers it communicates with.

This verification is necessary because, much like in physical security, access to protected spaces or resources must be controlled based on evidence of identity. In the physical world, guards at a secure facility do not simply allow anyone to enter; they check badges, keys, or biometric features, and may even recognize familiar individuals. The possession of a key or ID, knowledge of a code, or inherent physical traits serve as tangible proofs of identity. Similarly, in digital systems, where there is no direct way for the system to “see” or “sense” the claimant, we rely on analogous mechanisms: transmitted credentials and controlled challenges that emulate the same principles of trust established at a physical checkpoint.

The Three Classic Authentication Factors

Historically, the framework for authentication has been formalized in terms of factors of authentication, which fall into three mutually distinct categories, often summarized as:

• Something you know — a secret memorized and presented at the time of authentication, such as a password, PIN, or the answer to a security question. This is the oldest and most common factor, dating back to the earliest computer systems, where login prompts asked users to type a password. This factor is inexpensive to implement and does not require specialized hardware, but it suffers from significant weaknesses: secrets can be guessed, stolen, reused, or intercepted, and humans tend to choose weak or repetitive passwords for convenience.

• Something you have — a physical or digital token in your possession, such as a smart card, a time-based one-time password (TOTP) generator, a mobile app, or a hardware security key (e.g., FIDO2). The assumption here is that the token is difficult to duplicate and remains under the owner’s control. This factor mitigates some weaknesses of knowledge-based authentication by adding a physical element, but it introduces operational challenges: tokens can be lost, damaged, or stolen, and managing them at scale requires additional logistics and infrastructure.

• Something you are — an intrinsic characteristic of your body, or biometric evidence, such as a fingerprint, retinal or iris pattern, facial geometry, voice pattern, or even behavioral traits (like typing rhythm or gait). Biometric authentication is compelling because it is hard to forge and convenient for users. However, it also raises concerns about privacy, data permanence (you cannot change your fingerprint if it is compromised), and accuracy (with risks of false positives and false negatives).

These three factors are considered orthogonal, meaning that each addresses different kinds of risk and they are stronger when combined. This is the basis of multi-factor authentication (MFA), which requires the claimant to present evidence from at least two different categories (e.g., a password and a hardware token).

Historical Context and Formalization

The three-factor model has its roots in the late 20th century, when computer systems and networks began handling more sensitive and valuable information. Mainframe systems of the 1960s and 1970s were already using password-based mechanisms, but as networks expanded and threats increased, the need for stronger assurances became evident.

In particular, the U.S. Department of Defense’s Orange Book (Trusted Computer System Evaluation Criteria, TCSEC, 1983) emphasized the importance of identity verification in secure systems. Later, the National Institute of Standards and Technology (NIST) published a series of guidelines (notably NIST SP 800-63) that formalized identity assurance levels (IAL), authenticator assurance levels (AAL), and recommended the use of multiple factors for high-risk scenarios. These guidelines have since influenced international standards and commercial best practices.

Authentication vs. Authorization

It is also critical to distinguish authentication from authorization, two related but distinct components of access control.

• Authentication confirms who you are: it is the process of establishing the identity of the entity interacting with the system.
• Authorization determines what you are allowed to do: it governs the permissions and access rights granted to an authenticated entity.

Misunderstanding this distinction can lead to design flaws, where systems incorrectly assume that knowing who the user is automatically confers the right to perform certain actions, a fallacy that can open the door to privilege escalation and other attacks.

It is understandable to see professionals struggle with the distinction between authentication and authorization, especially when widely used standards themselves adopt misleading terminology. A notable example is the HTTP status code 401 Unauthorized, which seems to imply an authorization failure. However, RFC 7235 clarifies that it actually indicates the absence of valid authentication credentials, in other words, the client is unauthenticated. Conversely, if the client is authenticated but lacks permission to access the resource, the appropriate status is 403 Forbidden. Such ambiguous terminology can contribute to confusion, leading to poor error handling, security misconfigurations, and misleading diagnostics in practice.

Below is an expanded and more technically detailed version of your draft, preserving your structure and style while deepening the discussion:

The Importance of Multi-Factor Authentication

What is “strong” authentication?

The term strong authentication refers to an authentication mechanism that significantly raises the barrier against unauthorized access by requiring evidence from multiple independent factors, each of which presents distinct challenges to an attacker.

According to NIST SP 800-63B (“Digital Identity Guidelines”), strong authentication is achieved when authentication combines two or more different factors.

This taxonomy is rooted in the observation that each factor type involves a distinct trust assumption and failure mode. For example, a password can be guessed or leaked; a smartcard can be stolen; a fingerprint could theoretically be replicated, but achieving all three simultaneously is much more difficult.

This principle is also emphasized by regulatory frameworks such as the European Union’s Revised Payment Services Directive (PSD2), specifically its provision on Strong Customer Authentication (SCA), which mandates that authentication in financial services “validates the identity of the user through at least two factors which are independent from each other, and designed in such a way that the breach of one does not compromise the reliability of the other”.

The emphasis on independence is critical: if compromising one factor gives an attacker a pathway to compromise the second (e.g., a password reset sent to email when both accounts use the same password), the overall scheme fails to meet the standard of strong authentication.

Why does strong authentication matter?

Weak or single-factor authentication remains one of the most commonly exploited vulnerabilities in both consumer and enterprise environments.

For instance, the Verizon Data Breach Investigations Report (DBIR) consistently finds that over 80% of hacking-related breaches involve stolen, weak, or reused credentials. Similarly, Microsoft reports that enabling MFA can prevent over 99.9% of automated account compromise attacks, a figure reflecting the asymmetry between the effort needed to phish or guess a password and the effort needed to also obtain a second independent factor.

More granular studies (including Google’s analysis of millions of accounts) demonstrate that even lower-assurance factors, like SMS OTPs, reduce bulk phishing attack success by over 96%, and targeted attacks by over 76%. These figures improve further when higher-assurance factors (e.g., hardware security keys) are used.

The underlying reason is that MFA introduces a requirement that attackers compromise at least two unrelated mechanisms simultaneously: for example, intercepting a password and stealing a device or defeating a biometric reader. This drastically increases both the cost and complexity of attacks, often forcing attackers to move on to softer targets.

It also effectively neutralizes whole classes of attacks, such as credential stuffing and password spraying, which rely on automated exploitation of password reuse.

Common misconceptions about MFA

Despite its benefits, MFA is often misunderstood or improperly implemented, sometimes resulting in a false sense of security.

MFA vs. multi-step authentication

A frequent mistake is conflating multi-step authentication with multi-factor authentication. For example, many services send a one-time code (OTC) to a user’s email or SMS after password entry. While this adds an additional step, it does not necessarily add a true factor, because both steps may belong to the same category of authentication (typically something you know or something you control digitally).

Consider the following example:

• Step 1: Enter a password (something you know).
• Step 2: Retrieve a code from email (also something you know and control via another password).

Here, if the attacker compromises the email account, which may also be secured by the same password or an easily guessed one, both factors fall simultaneously, invalidating the intended security benefit.

For authentication to qualify as MFA, each factor must be drawn from a distinct category, and their compromise must be independent. Proper examples include:

• Password + hardware security token (knowledge + possession)
• Password + fingerprint (knowledge + inherence)

The problem with SMS and email OTPs

Another misconception is that SMS or email-based OTCs are inherently secure because they add a step after password entry. While they are better than no additional step, they suffer from serious weaknesses:

• SMS is vulnerable to SIM-swapping, SS7 protocol attacks, and social engineering of mobile carriers.
• Email can be compromised via phishing, password reuse, or malware, and is often the recovery vector for many accounts, making it a high-value target.

A well-documented example of this is the scam that targeted O2 customers in the UK, where attackers used social engineering to extract SMS OTCs under the guise of a prize verification process. Once customers revealed the codes, attackers immediately accessed and took over the accounts.

Biometric fallacies

Even biometric factors (something you are) are sometimes misused or misunderstood. People often believe that biometrics are foolproof. However:

• Many biometric systems are based on templates that can be stolen and replayed.
• Some can be spoofed with photographs, silicone molds, or deepfake techniques.
• Unlike passwords, compromised biometric data cannot be changed.

Therefore, biometrics are best used as one factor among others, not as a standalone mechanism.

Recovery paths can undermine MFA

Even properly designed MFA can be defeated if account recovery paths bypass it. For example, if a service allows a password reset via email without re-verifying possession of the second factor, an attacker can compromise the email account and reset the password, effectively bypassing MFA.

Best Practices for Stronger Authentication

Multi-factor authentication (MFA) has proven itself to be one of the most effective countermeasures against unauthorized access, credential stuffing, and account takeovers. However, its effectiveness depends critically on how it is implemented and understood.

In the preceding sections, we examined the foundational principles of authentication, clarified the distinction between authentication and authorization, and addressed common misconceptions about what constitutes “strong” authentication. Misapplied MFA, such as using two steps from the same factor category, or relying on insecure channels like SMS or email, can create a false sense of security.

Recommendations for implementing MFA effectively

To close, here are several best practices based on guidance from NIST, ENISA, and industry experience:

• Ensure factor independence: Select factors from different categories (know, have, are) and ensure compromise of one does not compromise the others.

• Prefer phishing-resistant methods: Whenever possible, opt for cryptographically bound hardware authenticators (e.g., FIDO2/WebAuthn security keys) or platform-based authenticators (e.g., Windows Hello, Touch ID) that resist phishing and man-in-the-middle attacks.

• Avoid SMS and email as primary second factors: Use these channels only as fallback or recovery mechanisms, not as primary authentication factors, due to their susceptibility to interception, SIM swapping, and social engineering.

• Educate users about social engineering: Many attacks bypass MFA by tricking users into revealing one-time codes or approving fraudulent login attempts. Training users to recognize and resist such attempts is essential.

• Monitor and adapt: Treat authentication as a living component of your security architecture. Monitor for evolving threats, evaluate the security of chosen factors periodically, and adapt policies as needed.

Final thoughts

Authentication is more than a technical hurdle; it is a cornerstone of trust in digital systems. Understanding the nuances of MFA, resisting the allure of superficial “two-step” schemes, and adopting strong, independent factors are essential steps toward robust access control.

By grounding your implementation in the principles outlined here, independence of factors, resistance to phishing, and resilience against social engineering, you can significantly reduce the risk of unauthorized access while preserving usability.

The Initial Question: Bytes or Runes?

The input is a DNA sequence, which contain only ASCII characters like A, C, G, and T. Naturally, I reached for a map to count each nucleotide.

With that set up, I added the iteration over the string using byte indexing (for i := 0; i < len(s); i++), since I remembered a comment on r/golang suggesting that byte iteration is idiomatic and efficient for ASCII-only strings.

package dna

import (
  "fmt"
)

type Histogram map[byte]int

func NewHistogram() Histogram {
  return Histogram{'A': 0, 'C': 0, 'G': 0, 'T': 0}
}

type DNA string

func (d DNA) Counts() (Histogram, error) {
  h := NewHistogram()

  for i := 0; i < len(d); i++ {
    if _, ok := h[d[i]]; !ok {
      return nil, fmt.Errorf("invalid nucleotide %q in DNA strand", d[i])
    }
    h[d[i]]++
  }

  return h, nil
}

A Surprising Benchmark Result

One of my favorite parts of Exercism is reviewing other submissions and comparing microbenchmark results. This time, I noticed that a solution by bobahop actually used rune iteration (for _, r := range s) and surprisingly, outperformed mine in microbenchmarks.

That caught me off guard. Had I been misled by Reddit?

I assumed that rune iteration would be slower due to the UTF-8 decoding overhead. I also knew my version was slower than bobahop’s due to using map lookups, while his used a switch, so I tested his version with byte iteration instead. Even then, his rune-based solution remained faster, just as he had noted on Exercism.

package dna

import "fmt"

type Histogram map[byte]int

type DNA string

const (
  nucA byte = 65
  nucC byte = 67
  nucG byte = 71
  nucT byte = 84
)

func (dna DNA) Counts() (Histogram, error) {
  results := Histogram{nucA: 0, nucC: 0, nucG: 0, nucT: 0}
  length := len(dna)
  for i := 0; i < length; i++ {
    nuc := dna[i]
    switch nuc {
    case nucA, nucC, nucG, nucT:
      results[nuc]++
    default:
      return nil, fmt.Errorf("invalid nucleotide '%c'", nuc)
    }
  }
  return results, nil
}

My Initial Approach

To get to the bottom of this, I created a small repo to isolate and benchmark different implementations using both byte and rune iteration.

I started with a simpler function: transcribing DNA to RNA.

func TranscribeDnaToRnaBytes(dna string, rna []byte) {
  for i := range len(dna) {
    switch dna[i] {
    case 'A':
      rna[i] = 'U'
    case 'C':
      rna[i] = 'G'
    case 'G':
      rna[i] = 'C'
    case 'T':
      rna[i] = 'A'
    }
  }
}

func TranscribeDnaToRnaRunes(dna string, rna []rune) {
  for i, n := range dna {
    switch n {
    case 'A':
      rna[i] = 'U'
    case 'C':
      rna[i] = 'G'
    case 'G':
      rna[i] = 'C'
    case 'T':
      rna[i] = 'A'
    }
  }
}

As expected, the benchmarks showed that byte iteration was slightly faster than rune iteration.

$ go test -bench='^(BenchmarkTranscribeDnaToRnaBytes|BenchmarkTranscribeDnaToRnaRunes)$' -benchtime=1000000x -benchmem
goos: linux
goarch: amd64
pkg: github.com/pessolato/strmapmicrobench
cpu: 12th Gen Intel(R) Core(TM) i9-12900F
BenchmarkTranscribeDnaToRnaBytes-24      1000000               331.4 ns/op             0 B/op          0 allocs/op
BenchmarkTranscribeDnaToRnaRunes-24      1000000               529.3 ns/op             0 B/op          0 allocs/op

Then I rewrote the nucleotide count functions, simplifying and updating them. I also used a more idiomatic byte loop (for i := range s) to see if that would help.

func CountNucleotidesByByteIndex(dna string) map[byte]int {
  chars := make(map[byte]int)
  for i := range len(dna) {
    chars[dna[i]]++
  }
  return chars
}

func CountNucleotidesByRuneRange(dna string) map[rune]int {
  chars := make(map[rune]int)
  for _, r := range dna {
    chars[r]++
  }
  return chars
}

But the performance difference persisted.

$ go test -bench='^(BenchmarkCountNucleotidesByByteIndex|BenchmarkCountNucleotidesByRuneRange)$' -benchtime=1000000x -benchmem
goos: linux
goarch: amd64
pkg: github.com/pessolato/strmapmicrobench
cpu: 12th Gen Intel(R) Core(TM) i9-12900F
BenchmarkCountNucleotidesByByteIndex-24          1000000              5191 ns/op             192 B/op          2 allocs/op
BenchmarkCountNucleotidesByRuneRange-24          1000000              1682 ns/op             192 B/op          2 allocs/op
PASS
ok      github.com/pessolato/strmapmicrobench   6.876s

At this point, I realized the bottleneck might not be the loop. So I turned to profiling.

CPU Profiling Tells the Real Story

I profiled both versions of the counting function and things started to click.

The version using byte indexing was calling the generic mapassign function, while the rune-based version was using mapassign_fast32, which is much faster.

That was the aha moment. The real issue wasn’t string iteration, but how maps work under the hood, especially based on the key type.

Go’s Internal Map Implementations

The Go runtime uses different internal implementations for map operations depending on the key type:

• For smaller key types like byte, it uses the slower generic mapassign.
• For int32 (which rune is an alias of), it uses optimized versions like mapassign_fast32.

So, despite rune iteration having more overhead, the faster map operations made the overall function faster.

To test this theory further, I added two more functions: one that uses byte iteration but casts to int16, and another that casts to rune:

func CountNucleotidesByByteIndexAsRune(dna string) map[rune]int {
  chars := make(map[rune]int)
  for i := range len(dna) {
    chars[rune(dna[i])]++
  }
  return chars
}

func CountNucleotidesByByteIndexAsInt16(dna string) map[int16]int {
  chars := make(map[int16]int)
  for i := range len(dna) {
    chars[int16(dna[i])]++
  }
  return chars
}

Benchmark results:

$ go test -bench='^BenchmarkCountNucleotidesBy.*$' -benchtime=1000000x -benchmem
goos: linux
goarch: amd64
pkg: github.com/pessolato/strmapmicrobench
cpu: 12th Gen Intel(R) Core(TM) i9-12900F
BenchmarkCountNucleotidesByByteIndex-24                  1000000              5177 ns/op             192 B/op          2 allocs/op
BenchmarkCountNucleotidesByByteIndexAsRune-24            1000000              1648 ns/op             192 B/op          2 allocs/op
BenchmarkCountNucleotidesByByteIndexAsInt16-24           1000000              5132 ns/op             192 B/op          2 allocs/op
BenchmarkCountNucleotidesByRuneRange-24                  1000000              1670 ns/op             192 B/op          2 allocs/op
PASS
ok      github.com/pessolato/strmapmicrobench   13.631s

Interestingly, int16 didn’t get any runtime optimization. But casting bytes to rune actually performed better than the native rune iteration, because byte iteration is inherently faster, and rune still benefits from optimized map handling.

Final Optimization: Arrays and Switches

Now that I understood the map overhead, I tried a more aggressive optimization. Since the nucleotide set is small and known, I replaced maps with a fixed-size array and a switch statement.

func CountNucleotidesArrayBytes(dna string) map[byte]int {
  chars := [4]int{}
  for i := range len(dna) {
    switch dna[i] {
    case 'A':
      chars[0]++
    case 'C':
      chars[1]++
    case 'G':
      chars[2]++
    case 'T':
      chars[3]++
    }
  }
  return map[byte]int{
    'A': chars[0],
    'C': chars[1],
    'G': chars[2],
    'T': chars[3],
  }
}

func CountNucleotidesArrayRunes(dna string) map[rune]int {
  chars := [4]int{}
  for i := range dna {
    switch dna[i] {
    case 'A':
      chars[0]++
    case 'C':
      chars[1]++
    case 'G':
      chars[2]++
    case 'T':
      chars[3]++
    }
  }
  return map[rune]int{
    'A': chars[0],
    'C': chars[1],
    'G': chars[2],
    'T': chars[3],
  }
}

And the benchmarks:

$ go test -bench='^(BenchmarkCountNucleotidesArray.*|BenchmarkCountNucleotidesByByteIndexAsRune)$' -benchtime=1000000x -benchmem
goos: linux
goarch: amd64
pkg: github.com/pessolato/strmapmicrobench
cpu: 12th Gen Intel(R) Core(TM) i9-12900F
BenchmarkCountNucleotidesByByteIndexAsRune-24            1000000              1642 ns/op             192 B/op          2 allocs/op
BenchmarkCountNucleotidesArrayBytes-24                   1000000               412.9 ns/op           192 B/op          2 allocs/op
BenchmarkCountNucleotidesArrayRunes-24                   1000000               680.5 ns/op           192 B/op          2 allocs/op
PASS
ok      github.com/pessolato/strmapmicrobench   2.739s

The result? Substantial performance gains, thanks to completely bypassing map lookups.

Conclusion

This whole detour was a great reminder: Always benchmark and profile when performance matters. Micro-optimizations like using bytes over runes can help, but they pale in comparison to the deeper costs of how your data structures behave at runtime.

Key Takeaways

• Byte iteration is slightly faster than rune iteration.
• Map key type matters a lot—Go uses specialized fast paths for certain types.
• Profiling is essential for spotting unexpected performance bottlenecks.
• When the key space is small and fixed, arrays + switch can outperform maps significantly.

If you’re curious, you can find all the code and benchmark results here: https://github.com/pessolato/strmapmicrobench