Now Reading
Optimizing Go string operations with sensible examples | by Alex Bledea | Dec, 2023

Optimizing Go string operations with sensible examples | by Alex Bledea | Dec, 2023

2023-12-02 07:11:02

12 min learn

21 hours in the past

Picture by Chad Kirchoff on Unsplash

I’m going to point out you ways I took a quite simple program and made it run nearly 5 occasions quicker, with very minimal changes. You could know that I’m doing Advent of Code, and I’ll share my resolution from day 2, and the way I used to be in a position to enhance its pace. (and when you’re not collaborating within the contest, you positively ought to!)

Simply to provide some background, the competition favors coding pace over resolution effectivity, so as a way to remedy the issue rapidly I wrote some working code as quick as I can, with out considering of any optimization. More often than not, that can run nearly immediately, a minimum of for a part of the issues. The creator of the contests mentions that each downside has an answer which takes not than 15 seconds on 10-year-old {hardware}.

For these curious, my contest occasions for this downside had been 10:34, rank 1426 and 12:56, rank 1071.

For that motive, I discover it attention-grabbing to start out from my authentic options and discover methods to enhance it, both by way of higher algorithms or language-specific methods. It is a superb train which helps me enhance each my summary considering and my language information. Along with that, it’s an ideal thought after fixing the issue to browse the subreddit and browse not solely different individuals’s approaches and options, but additionally what different languages can do.

For this text, I’ll be speaking about lower-level langauge optimizations, whereas the core resolution will keep the identical. I need to showcase how very small adjustments that might usually be thought-about “stylistic” can considerably have an effect on your program’s efficiency. These optimizations are particular to Go, however most of the ideas will be translated to totally different langauges.

So let’s begin with the issue assertion, which I’ll simplify for brevity. Your enter consists of a bunch of video games, every having this format:

Sport 1: 4 blue, 7 crimson, 5 inexperienced; 3 blue, 4 crimson, 5 inexperienced; 3 crimson, 11 inexperienced
Sport 2: 2 blue, 8 crimson, 1 inexperienced; 15 blue, 2 inexperienced, 8 crimson;
Sport 3: 1 crimson, 6 inexperienced, 4 blue

The sport has an index, adopted by the rounds which were performed, separated by ;. What you’re required to do for half (a) is:

  • discover all video games by which each spherical has at most 12 crimson, 13 inexperienced and 14 blue;
  • add up all these video games quantity.

For instance, in Sport 1, no spherical exceeded the restrict for crimson, inexperienced, blue. Nonetheless, in Sport 2, the second spherical exceeded the utmost restrict for blue. Within the case above, the video games which fulfill the situation are the primary and the third, which means the answer could be 1+3=4

Since half (b) is much like half (a) and the identical optimizations apply, I’ll solely be discussing the adjustments for half (a).

Now, let’s get to the enjoyable stuff. We will rapidly construct up an thought for some algorithm, with the next steps:

  • begin with a counter;
  • learn every line individually;
  • discover the part akin to the scores (after Sport x:);
  • get all particular person rounds (x inexperienced, x crimson, x blue);
  • verify if any particular person spherical doesn’t fulfill the situation;
  • if all particular person rounds are good, increment the counter with the sport quantity (which on this case is similar as the road quantity, simplifying the issue a bit).

That’s the pseudocode we’ll be mindful. The core algorithm is just not tough in any respect; a lot of the effort will probably be invested in parsing the strings. Let’s check out my first working contest solution (which I refactored right here for readability, the precise resolution is within the linked commit hash):

func part1() int {
sumOfGameIndices := 0

// Course of every sport
// inputLines is an array of strings containing
// every line of the video games file
for gameIndex, line := vary inputLines {

// Take away the "Sport x:" prefix
elements := strings.Break up(line, ": ")
sport := elements[1]

// Course of every spherical of the present sport
rounds := strings.Break up(sport, "; ")

isPossible := false
for _, spherical := vary rounds {
crimson, inexperienced, blue := findScores(spherical)
if isRoundPossible(crimson, inexperienced, blue) {
isPossible = true
} else {
isPossible = false

// If just one spherical is just not potential, there's
// no have to course of the opposite ones.
if isPossible {
sumOfGameIndices += gameIndex + 1
return sumOfGameIndices

The rationale why I parsed the enter in an array of strings with the strains is to streamline the benchmarks implementations. It’s after all potential and extra environment friendly to parse every line after studying it utilizing its file descriptor, however which will contain background noise in your benchmarks like system calls or reminiscence allocations. For instance, Go’s bufio.Scanner buffered file reader does a lot of allocations if utilizing scanner.Textual content(), polluting benchmarks.

In fact, studying the file into an array of strings additionally allocates, perhaps much more, and makes use of way more reminiscence, however doesn’t intervene wtih benchmarks.

Let’s additionally reveal the findScores() perform:

// findScores computes the scores of a single spherical.
func findScores(spherical string) (int, int, int) {

// initialize the crimson, inexperienced, blue values to 0
var crimson, inexperienced, blue int

See Also

individualScores := strings.Break up(spherical, ", ")
for _, rating := vary individualScores {

scoreWithColor := strings.Break up(rating, " ")
scoreStr := scoreWithColor[0]
shade := scoreWithColor[1]

// convert rating to integer
rating, _ := strconv.Atoi(scoreStr)
if shade == "crimson" {
crimson += rating
if shade == "inexperienced" {
blue += rating
if shade == "blue" {
inexperienced += rating
return crimson, blue, inexperienced

And eventually, the easy isRoundPossible() implementation:

// isRoundPossible determines if the spherical is legitimate or not.
func isRoundPossible(crimson, inexperienced, blue int) bool {
return crimson <= 12 && inexperienced <= 13 && blue <= 14

There isn’t actually a lot you could possibly do to enhance the core algorithm right here, it’s primarily simply including the numbers from the file. Nonetheless, can you see some (maybe stylistic) implementation particulars that make this program slower?

With the code contemporary in thoughts, let’s put up some benchmarks to watch this system’s assets (the ret and r dance is to keep away from dead code compiler optimization).

var ret int
func BenchmarkPart1(b *testing.B) {
r := 0
for n := 0; n < b.N; n++ {
r = part1()
ret = r

And under are the outcomes. I ran the benchmark a couple of occasions, after a contemporary working system restart (which improved the typical execution time by about 1000ns):

goos: home windows
goarch: amd64
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkPart1-16 29626 78729 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 29956 79863 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30465 79246 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30079 79018 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30069 79062 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 29917 79491 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30338 79184 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30518 79395 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30187 79296 ns/op 51248 B/op 1383 allocs/op
BenchmarkPart1-16 30144 79508 ns/op 51248 B/op 1383 allocs/op
okay command-line-arguments 66.533s

I’ll simply interpret the related bits and keep away from the Go benchmark specifics. We will see that this system took on common round 79,000 nanoseconds to execute (that’s ~0.08 miliseconds!), allotted 50KB on the heap throughout each execution, unfold throughout 1383 complete allocations.

At first look, this doesn’t actually inform us something about this system since we don’t have one thing to match it to, however the variety of reminiscence allocations stands out a bit. If we omit processing and storing the file in an array of strings (which isn’t benchmarked), it seems like we’re doing fairly a couple of allocations when working the answer. That appears a bit odd; we’re simply studying some numbers from an enter string and doing a little calculations. The numbers might simply dwell on the stack, and the enter string is on the heap already. It doesn’t really feel like we would wish any extra heap allocations!

Heap allocations are costly operations, way more costly than stack allocations. There are a lot of assets on the market which explain why (simply Google heap vs stack allocations), however the clarification I like probably the most comes from this stackoverflow post. Overly simplified, a stack allocation is only a few CPU directions, whereas a heap allocation implementation has about 10,000 strains of C code)

However the place are all these allocations coming from? One thing stands out: we’re doing quite a lot of strings.Break up() to parse this enter. This technique can be widespread sufficient throughout a number of languages that it appears pure to method the enter parsing this fashion. It may very well be a place to begin.

In fact, that’s simply an assumption. Nonetheless, a CPU profile of this system confirms the suspicion (I needed to run this system 20,000 occasions in a loop as a result of it was finishing too quick to even retrieve a single CPU pattern):

Source Link

What's Your Reaction?
In Love
Not Sure
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top