In the previous blog post I discussed two different ways of merging n channels in Go, but we did not discuss which ones was faster. In the meanwhile a third way of merging channels was proposed in a YouTube comment.

This blog post will show that third way and compare all of them from a performance point of view, analyzed using benchmarks.

A third way of merging channels

Two episodes ago we discussed how two channels could be merged, using a single goroutine and nil channels. We’ll refer to that function here as mergeTwo. A justforfunc viewer proposed a way to use this function and recursion to provide a way to merge n channels.

The solution is quite smart. If we have:

• one channel, we return that channel.
• two channels or more, we merge a half of the channels and then merge them using the result of those using the efficient function.

What about no channels? We will return an already closed channel.

Written in code it would look like this:

This is a nice solution that avoids using reflection and also reduces the number of goroutines needed. On the other hand, it uses more channels than before!

So, which one is fastest? Time for benchmarks!

Writing a benchmark

Testing and benchmarks are integrated very tightly with the Go tooling, and writing a benchmark is as simple as writing a function with a name starting with Benchmark and the appropriate signature.

The only parameter a benchmark receives is of type testing.B and it defines the number of times we should perform the operation we’re benchmarking. This is done for statistical significance, by default benchmarks are given a number of iterations that will make the function run for a whole second.

Ok, so now we know pretty much everything we need to know to write a benchmark for one of our functions.

Benchmarking all our functions

Ok, so we’re ready to write benchmarks for each function!

One for merge:

One for mergeReflect:

And finally. one for mergeRec:

And now we can finally run them!

➜ go test -bench=.
goos: darwin
goarch: amd64
pkg: github.com/campoy/justforfunc/27-merging-chans
BenchmarkMerge-4                  200000              7074 ns/op
BenchmarkMergeReflect-4           100000             11904 ns/op
BenchmarkMergeRec-4               500000              2475 ns/op
PASS
ok      github.com/campoy/justforfunc/27-merging-chans  4.077s

Great, so using recursion is the fastest possible option. Let’s believe it for now!

Using sub-benchmarks and b.Run

Unfortunately, in order to benchmark three functions we’re repeating lots of code. Wouldn’t it be nice if we could write our benchmark once?

We can write a function that iterates over our three functions:

Unfortunately, that simply gives a single and pretty meaningless measure, mixing all performances.

➜ go test -bench=.
goos: darwin
goarch: amd64
pkg: github.com/campoy/justforfunc/27-merging-chans
BenchmarkMerge-4           50000             22440 ns/op
PASS
ok      github.com/campoy/justforfunc/27-merging-chans  1.386s

Luckily, we can easily create subbenchmarks by calling testing.B.Run, similarly as subtests with testing.T.Run. In order to do so, we need a name, which is actually a pretty good idea from a documentation point of view, anyway.

When we run these benchmarks we’ll now see three different results as we wished.

➜ go test -bench=.
goos: darwin
goarch: amd64
pkg: github.com/campoy/justforfunc/27-merging-chans
BenchmarkMerge/goroutines-4               200000          6145 ns/op
BenchmarkMerge/reflect-4                  200000         10962 ns/op
BenchmarkMerge/recursion-4                500000          2368 ns/op
PASS
ok      github.com/campoy/justforfunc/27-merging-chans  4.829s

Sweet! With way less code we’re still able to benchmark all of our functions.

Benchmarking multiple values of N

So far we’ve seen that for a single channel the recursive algorithm is the fastest, but what about other values of N?

We could probably just change the value of N many times and see how it goes. But we could also just use a for loop!

In the code below we iterate over the powers of 2 from 1 to 1024, and use a combination of the function we’re benchmarking and the value of N as the benchmark name.

Let’s run the benchmarks!

➜ go test -bench=.
goos: darwin
goarch: amd64
pkg: github.com/campoy/justforfunc/27-merging-chans
BenchmarkMerge/goroutines/1-4             200000          6919 ns/op
BenchmarkMerge/goroutines/2-4             100000         13212 ns/op
BenchmarkMerge/goroutines/4-4              50000         25469 ns/op
BenchmarkMerge/goroutines/8-4              30000         50819 ns/op
BenchmarkMerge/goroutines/16-4             20000         88566 ns/op
BenchmarkMerge/goroutines/32-4             10000        162391 ns/op
BenchmarkMerge/goroutines/64-4              5000        299955 ns/op
BenchmarkMerge/goroutines/128-4             3000        574043 ns/op
BenchmarkMerge/goroutines/256-4             1000       1129372 ns/op
BenchmarkMerge/goroutines/512-4             1000       2251411 ns/op
BenchmarkMerge/goroutines/1024-4             300       4760560 ns/op
BenchmarkMerge/reflect/1-4                200000         10868 ns/op
BenchmarkMerge/reflect/2-4                100000         22335 ns/op
BenchmarkMerge/reflect/4-4                 30000         54882 ns/op
BenchmarkMerge/reflect/8-4                 10000        148218 ns/op
BenchmarkMerge/reflect/16-4                 3000        543921 ns/op
BenchmarkMerge/reflect/32-4                 1000       1694021 ns/op
BenchmarkMerge/reflect/64-4                  200       6102920 ns/op
BenchmarkMerge/reflect/128-4                 100      22648976 ns/op
BenchmarkMerge/reflect/256-4                  20      90204929 ns/op
BenchmarkMerge/reflect/512-4                   3     383579039 ns/op
BenchmarkMerge/reflect/1024-4                  1    1676544681 ns/op
BenchmarkMerge/recursion/1-4              500000          2658 ns/op
BenchmarkMerge/recursion/2-4              100000         14707 ns/op
BenchmarkMerge/recursion/4-4               30000         44520 ns/op
BenchmarkMerge/recursion/8-4               10000        114676 ns/op
BenchmarkMerge/recursion/16-4               5000        261880 ns/op
BenchmarkMerge/recursion/32-4               3000        560284 ns/op
BenchmarkMerge/recursion/64-4               2000       1117642 ns/op
BenchmarkMerge/recursion/128-4              1000       2242910 ns/op
BenchmarkMerge/recursion/256-4               300       4784719 ns/op
BenchmarkMerge/recursion/512-4               100      10044186 ns/op
BenchmarkMerge/recursion/1024-4              100      20599475 ns/op
PASS
ok      github.com/campoy/justforfunc/27-merging-chans  61.533s

We can see that even though the recursive algorithm is the fastest for a single channel, very quick the solution with many goroutines outperforms the others.

We can also this by plotting these numbers with some quick Python. Stop acting shocking I somtimes write in Python too!

It’s hard to see the difference, so let’s use a logarithmic scale for the Y axis (simply add plt.yscale('log')).

Managing the benchmark timer

There’s an obvious issue with the way we’re measuring performance. We’re also counting the time it takes to create the N channels for our tests, which adds cost that is not relevant to our algorithms.

We can avoid this by using b.StopTimer() and b.StartTimer().

The results are not that different to our previous benchmark, but we can see the timing difference increases with the value of N.

Can we make them faster?

We finally have a good view of how each function performs for different sizes of N. This is great, but doesn’t really help us making our functions faster.

How could we know more? Well, benchmarks take us only so far, but the next tool we we can use is profiling! Wanna know more? Next episode coming up in two weeks.

Thanks

If you enjoyed this episode make sure you share it and subscribe to justforfunc! Also, consider sponsoring the series on patreon.

Analyzing the performance of Go functions with benchmarks was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog post is complementary to episode 27 of justforfunc which you can watch right below.

Two weeks ago I explained how nil channels were useful for some important concurrency patterns, specifically when merging two channels. As a result, because this is the internet, many replied telling me there’s better ways to merge two channels than that. And guess what, I agree!

The algorithm I showed is useful for only two channels. Today we’re going to explore how to handle nchannels where n is not known at compilation time. This means we can’t simply use select over all the channels, so what are the options?

First way: using N goroutines

The first approach is to create a new goroutine per channel. Each one of these goroutines will range over a channel and send each one of those elements to the output channel.

Or in code:

This code is wrong in a couple of ways. Can you see them?

Let’s first see one of the issues. In order to run it I define a new asChan function, which is explained in the previous justforfunc episode, and use it from the main function as follows.

Ok, so what’s the problem when we run it when the data race detector enabled, aka -race?

$ go run -race main.go
==================
WARNING: DATA RACE
Read at 0x00c420090018 by goroutine 9:
  main.merge.func1()
      /Users/francesc/src/github.com/campoy/campoy.cat/site/content/blog/main.go:35 +0x3f

Previous write at 0x00c420090018 by main goroutine:
  main.merge()
      /Users/francesc/src/github.com/campoy/campoy.cat/site/content/blog/main.go:33 +0xf0
  main.main()
      /Users/francesc/src/github.com/campoy/campoy.cat/site/content/blog/main.go:13 +0x282

Goroutine 9 (running) created at:
  main.merge()
      /Users/francesc/src/github.com/campoy/campoy.cat/site/content/blog/main.go:34 +0x9b
  main.main()
      /Users/francesc/src/github.com/campoy/campoy.cat/site/content/blog/main.go:13 +0x282
==================

Fixing a data race

Indeed, we’re accessing the c variable defined in the for loop from many goroutines. This is dangerous, but luckily there’s a common idiom that solves the problem. Simply pass the variable as a parameter, that way it will be duplicated and each goroutine will end up with a different variable to itself.

Now that the data race has been removed, let’s run the program again.

$ go run main.go
20
10
0
...
9
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
main.main()
        /Users/francesc/src/github.com/campoy/campoy.cat/site/content/blog/main.go:13 +0x24a
exit status 2

Ok, this is better and it looks pretty good until the end when everything crashes. What’s going on? Well, the main goroutine is blocked waiting for anyone to close the channel on which it’s ranging. Unfortunately we forgot to close the channel at all.

Closing the output channel

When should we close the channel? Well, once all goroutines have finished sending values into it. When exactly is that? We don’t really know, but we can simply “wait” for them to be done.

And how do you wait for a group of things? A WaitGroup, defined in the sync package.

A WaitGroup has 3 main methods: - Add adds a given number of things to be done. - Done indicates one of those things is done. - Wait blocks until the number of things to be done goes down to zero.

Let’s fix our program and close the output channel when it’s appropriate.

Note that Wait is called in a different goroutine.

Second way: using reflect.Select

A second way of solving the same problem is using reflect.Select which provides a Select operation on a slice of SelectCases.

In order to call it we’re going to create a slice of SelectCase that contains an element per channel.

Then we can call reflect.Select and send the value we receive to the out channel. Unless channel we received from was closed, in which case we should remove the case from the slice. This is very similar to what we did setting the channel to nil in the previous episode.

This should be done for as long there’s at least a non closed channel. In our case this is equivalent to the slice not being empty.

So the full code is as follows.

Running this code will also work and finish without panicking.

Which one is fastest?

The first solution uses a linear number of goroutines (one per channel) so that could somehow get slow at some point.

But the second solution uses reflection and we all know that’s pretty slow, right?

So which one is fastest? I sincerely don’t know! And that’s the question I’ll solve in the next episode when we’ll talk about benchmarks.

You can now read it here!

Analyzing the performance of Go functions with benchmarks

Thanks

If you enjoyed this episode make sure you share it and subscribe to justforfunc! Also, consider sponsoring the series on patreon.

Two ways of merging N channels in Go was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m a Developer Advocate for Google Cloud Platform and work with the Go team, so I’ll mostly be writing in Go and running things on Google Cloud … but not only!

The first episode is obviously number zero:

And the second one is already available, where I review some code recently written by a friend on GitHub:

If you enjoyed these videos you should definitely register to the YouTube channel for more! I’ll try to post stuff weekly, at least at the beginning.

You can send proposals for topics and projects by commenting on the videos, or on Twitter as @francesc.

JustForFunc: “hello, world” and a code review was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

For almost a year I’ve been living in this apartment where whenever rings at the gate downstairs my phone will ring, then I have to press the button 9 to open the door. I’m sure you’ve seen some of these systems before … they work, but I also find it pretty annoying to have to answer the phone every time. So …

could I use speech recognition to open the gate with a spoken password?

That’s a demo! And actually, if you think about it it’s not too far from the door/paintings in Harry Potter!

Anyway, I decided it was a great opportunity to build a demo using Twilio and Google Cloud Speech API together. I had never used any of those before, so the video ended up being longer that expected… but here they are!

Part 1: I build the basic architecture using Google App Engine and Twilio to open the door regardless of who is calling.

Part 2: I add speech recognition by recording the phone call and sending the mp3 to Google Cloud Speech API.

I hope you enjoy them 😊

The Magic Gate #justforfunc 3 was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

As an experiment, this is the first blog post form of a justforfunc episode, you can also watch the corresponding episode.

The initial program

We start with a very simple program, copied partly from Wikipedia, that creates a Mandelbrot fractal by first computing the color of each pixel, and then writing the corresponding image to a PNG file.

func main() {
	f, err := os.Create(output)
	if err != nil {
		log.Fatal(err)
	}

	img := createSeq(width, height)

	if err = png.Encode(f, img); err != nil {
		log.Fatal(err)
	}
}

In this first iteration createSeq, which calls pixel to compute the color of each pixel, one after the other.

func createSeq(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))
	for i := 0; i < width; i++ {
		for j := 0; j < height; j++ {
			m.Set(i, j, pixel(i, j, width, height))
		}
	}
	return m
}

Finally, the part that is basically extracted from Wikipedia allows us to compute the color of a given pixel. The complexity value determines how complex the fractal gets, values from 4 to 2048 give various and interesting effects. Play with this!

func pixel(i, j, width, height int) color.Color {
	// Play with this constant to increase the complexity of the fractal.
	// In the justforfunc.com video this was set to 4.
	const complexity = 1024

	xi := norm(i, width, -1.0, 2)
	yi := norm(j, height, -1, 1)

	const maxI = 1000
	x, y := 0., 0.

	for i := 0; (x*x+y*y < complexity) && i < maxI; i++ {
		x, y = x*x-y*y+xi, 2*x*y+yi
	}

	return color.Gray{uint8(x)}
}

How fast is it?

At this point our program runs and creates a cool fractal, and it takes (in my laptop) around 4.7 seconds.

$ time ./mandelbrot
./mandelbrot  4.44s user 0.01s system 99% cpu 4.466 total

The resulting image is this cool fractal.

Can we make it faster? pprof

In order to obtain more information about how the program performs we can profile the CPU usage with the runtime/pprof package in the standard library.

Simply adding two lines of code at the beginning of the main function.

pprof.StartCPUProfile(os.Stdout)
defer pprof.StopCPUProfile()

Now if we run the program again it will output pprof profiling information into the standard output.

$ time ./mandelbrot > cpu.pprof
./mandelbrot > cpu.pprof  5.25s user 0.02s system 96% cpu 5.469 total

Interestingly, adding pprof has not slowed the program much! And in exchange of that temporary performance hit we get much visibility on what the program spent its time on.

Let’s open pprof and see what it spent its time on.

$ go tool pprof cpu.pprof
Type: cpu
Time: Oct 23, 2017 at 11:04am (CEST)
Duration: 5.45s, Total samples = 4.53s (83.13%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof)

We can now list how much time we spend in each function we call with list.

(pprof) list main.main
Total: 4.53s
ROUTINE ======================== main.main in /Users/campoy/src/github.com/campoy/justforfunc/22-perf/main.go
         0      4.15s (flat, cum) 91.61% of Total
         .          .     39:   f, err := os.Create(output)
         .          .     40:   if err != nil {
         .          .     41:           log.Fatal(err)
         .          .     42:   }
         .          .     43:
         .      3.89s     44:   img := createSeq(width, height)
         .          .     45:
         .      260ms     46:   if err = png.Encode(f, img); err != nil {
         .          .     47:           log.Fatal(err)
         .          .     48:   }
         .          .     49:}
         .          .     50:
         .          .     51:// createSeq fills one pixel at a time.

Ok, so it seems we spent most of the time in createSeq, makes sense!

(pprof) list main.createSeq
Total: 4.53s
ROUTINE ======================== main.createSeq in /Users/campoy/src/github.com/campoy/justforfunc/22-perf/main.go
         0      3.89s (flat, cum) 85.87% of Total
         .          .     51:// createSeq fills one pixel at a time.
         .          .     52:func createSeq(width, height int) image.Image {
         .          .     53:   m := image.NewGray(image.Rect(0, 0, width, height))
         .          .     54:   for i := 0; i < width; i++ {
         .          .     55:           for j := 0; j < height; j++ {
         .      3.89s     56:                   m.Set(i, j, pixel(i, j, width, height))
         .          .     57:           }
         .          .     58:   }
         .          .     59:   return m
         .          .     60:}
         .          .     61:

Great, again most of the time is in the line calling pixel, and what does pixel do?

(pprof) list main.pixel
Total: 4.53s
ROUTINE ======================== main.pixel in /Users/campoy/src/github.com/campoy/justforfunc/22-perf/main.go
     2.01s      3.87s (flat, cum) 85.43% of Total
         .          .    209:func pixel(i, j, width, height int) color.Color {
         .          .    210:   // Play with this constant to increase the complexity of the fractal.
         .          .    211:   // In the justforfunc.com video this was set to 4.
         .          .    212:   const complexity = 1024
         .          .    213:
         .       10ms    214:   xi := norm(i, width, -1.0, 2)
         .          .    215:   yi := norm(j, height, -1, 1)
         .          .    216:
         .          .    217:   const maxI = 1000
         .          .    218:   x, y := 0., 0.
         .          .    219:
     1.29s      1.29s    220:   for i := 0; (x*x+y*y < complexity) && i < maxI; i++ {
     720ms      720ms    221:           x, y = x*x-y*y+xi, 2*x*y+yi
         .          .    222:   }
         .          .    223:
         .      1.85s    224:   return color.Gray{uint8(x)}
         .          .    225:}

Ok, so we spend a decent amount of time computing multiplications in that loop, also a lot of time allocating pixels in line 224.

So what now?

We have a better idea of what our program spends most of the time: computing pixel values. But what do we do now? It seems reasonable that a program that generates fractals spends most of the time, well … generating fractals!

There’s things we could do to try and optimize the CPU time, but in this post instead of going that way, we’re going to see what other things we can do to speed up the program without changing the pixelfunction.

Meet the tracer

One of the problems of pprof is that it is a stastistical way of discovering how often a given piece of code is running. It allows us to understand what the program is running when it’s on the CPU, but what about when it’s not? We’re missing information that we can not (or at least not easily) extract from a pprof trace.

The Go execution tracer, rather than pinging the program regularily to understand what it is up to, it instead hooks to the Go runtime to log every single event we care about. These events include:

• go routine creation and destruction
• blocking events such as channel or mutex operations
• system calls
• etc

The most powerful side of the Go execution tracer is the amazing visualization it generates, which allows us to see the “empty” space in our program.

Let’s create a trace from this program, by simply replacing our pprof calls by calls to the runtime/tracepackage also in the standard library.

trace.Start(os.Stdout)
defer trace.Stop()

Then we can execute the program again an visualize the trace with go tool trace.

$ time ./mandelbrot > seq.trace
./mandelbrot > seq.trace  5.11s user 0.04s system 99% cpu 5.176 total

$ go tool seq.trace
2017/10/23 11:16:55 Parsing trace...
2017/10/23 11:16:55 Serializing trace...
2017/10/23 11:16:55 Splitting trace...
2017/10/23 11:16:55 Opening browser

This will open a browser and display a webpage that, among others, has a link to View Trace. Click there and you should be something like this:

I invite you to explore the visualization, specially the garbage collection event towards the end. But the most important point here is everything we can’t see.

Do you see those 8 Proc? Those are the eight processors that my laptop has. Only one of them, processor 2 in my case, is really doing any work!

One of Go’s powers is easy concurrency, right? Well, it’s time to use those, because we clearly are wasting CPU time by not expressing our program in a concurrent way which would enable parallelism.

More concurrency, more parallelism, more speed!

Let’s go to a ridiculuous extreme and decide that, since each pixel can be computed concurrently, we are going to create a goroutine per pixel. This, for our 2048x2048 image, means we’re going to create over four million goroutines. We say goroutines are cheap … so let’s seee if that’s true!

The function that creates a goroutine per pixel is called createPixel:

func createPixel(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))
	var w sync.WaitGroup
	w.Add(width * height)
	for i := 0; i < width; i++ {
		for j := 0; j < height; j++ {
			go func(i, j int) {
				m.Set(i, j, pixel(i, j, width, height))
				w.Done()
			}(i, j)
		}
	}
	w.Wait()
	return m
}

Ok, so first of all let’s run it without the tracer to see how fast it is and compare it to the sequential option.

$ time ./mandelbrot
./mandelbrot  13.70s user 1.53s system 471% cpu 3.234 total

Wow, it’s actually faster! It used much more CPU time (13.70s) but since it distributed it so efficiently across our eight CPUs, the total time it spent running was only 3.2 seconds.

Victory! Right?

Well, let’s create a trace and see what it looks like.

$ time ./mandelbrot > px.trace
./mandelbrot > px.trace  25.64s user 5.46s system 502% cpu 6.184 total

Wow, we spent almost twice of CPU cycles than before! Why is this? Well, the tracer has a performance cost, and in this case we’re logging each and every goroutine we create. This, by itself, might point to problem in our solution.

Let’s open the trace, and be warned it’s not going to be fast!

$ go tool trace px.trace
2017/10/23 11:29:17 Parsing trace...
2017/10/23 11:29:58 Serializing trace...
2017/10/23 11:30:13 Splitting trace...
2017/10/23 11:30:49 Opening browser

Note: you will need to pass the binary as before px.trace if you are using Go 1.8 or earlier versions.

The trace has been split into many pieces to avoid overloading the browser. Let’s open one somewhere around the center. This, again, will be quite slow. Patience is your friend.

It seems like the CPUs are really busy this time! But, let’s zoom in a bit.

Oh, that doesn’t seem like it’s very well utilized after all. We’ve created too many goroutines, which causes too much pressure on the runtime, both the scheduler and the garbage collector, and it shows as contention and wasted CPU time.

On go routines and dataraces

Ok, so … is this program correct? Are there any data races? The easiest way to show that there are no obvious data races is by using the data race detector.

To do so you can simply add -race to the go build|run|test command. If you try it with the program as is it will fail:

$ go build -o mandelbrot -race
$ time ./mandelbrot
race: limit on 8192 simultaneously alive goroutines is exceeded, dying
./mandelbrot  0.49s user 1.00s system 99% cpu 1.483 total

There’s a limit of 8192 alive goroutines, and with 4 millions we clearly exceed it. Instead let’s use the benchmarks I wrote, which generate smaller images.

Let’s run it with and without the data race detector to compare the performances.

$ go test -bench=Pixel
goos: darwin
goarch: amd64
pkg: github.com/campoy/justforfunc/22-perf
BenchmarkPixel/64-8                 2000           1003116 ns/op
BenchmarkPixel/128-8                 300           5003258 ns/op
BenchmarkPixel/256-8                 100          19693236 ns/op
BenchmarkPixel/512-8                  20          86670280 ns/op
PASS
ok      github.com/campoy/justforfunc/22-perf   7.894s

$ go test -bench=Pixel -race
go test -bench=Pixel -race
goos: darwin
goarch: amd64
pkg: github.com/campoy/justforfunc/22-perf
BenchmarkPixel/64-8                   10         181391401 ns/op
BenchmarkPixel/128-8                   2         729349776 ns/op
BenchmarkPixel/256-8                   1        2923114988 ns/op
BenchmarkPixel/512-8                   1        12477182754 ns/op
PASS
ok      github.com/campoy/justforfunc/22-perf   20.626s

There’s a clear difference, but the good news it’s it didn’t panic. This means no data races were detected. There might be some data race, but the code we just run didn’t cause any.

In a previous version of the code (see the video for more details) the anonymous function in the go routine didn’t get any parameters. This caused a data race on both i and j.

func createPixel(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))
	var w sync.WaitGroup
	w.Add(width * height)
	for i := 0; i < width; i++ {
		for j := 0; j < height; j++ {
			go func() {
				m.Set(i, j, pixel(i, j, width, height))
				w.Done()
			}()
		}
	}
	w.Wait()
	return m
}

It’s also worth mentioning that m.Set being called from different go routines is not a problem since we are modifying different positions in a preallocated slice.

Finding compromise in between too few and too many

Ok, so one goroutine is too few, but four millions is too many. Let’s go right in between and go with one goroutine per column. This time we’ll call createCol which creates a goroutine per column, so “only” 2048 of them.

func createCol(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))
	var w sync.WaitGroup
	w.Add(width)
	for i := 0; i < width; i++ {
		go func(i int) {
			for j := 0; j < height; j++ {
				m.Set(i, j, pixel(i, j, width, height))
			}
			w.Done()
		}(i)
	}
	w.Wait()
	return m
}

As before, let’s run it without trace first to see whether we improve the 3.2 seconds we got before.

$ time ./mandelbrot
./mandelbrot  4.90s user 0.02s system 499% cpu 0.985 total

Ok, we went from almost five seconds, to three, and now less than a second!

What does the trace look like? Let’s check it out.

$ time ./mandelbrot > col.trace
./mandelbrot > col.trace  4.79s user 0.02s system 498% cpu 0.966 total

$ go tool trace col.trace
2017/10/23 11:41:29 Parsing trace...
2017/10/23 11:41:29 Serializing trace...
2017/10/23 11:41:30 Splitting trace...
2017/10/23 11:41:30 Opening browser

That looks pretty good! We can see that the CPUs are pretty busy first, then we move to one goroutine to encode the image into the file. Let’s zoom in, though (feeling like CSI already?).

That looks very good! But, can we do better?

What about the “workers” concurrency pattern?

If you’ve written enough Go, you migh have encountered the “workers” pattern, where we create a small number of workers (eight in this case) which fetch tasks from a channel. We also use a sync.WaitGroup to make sure all workers are done before exiting.

func createWorkers(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))

	type px struct{ x, y int }
	c := make(chan px)

	var w sync.WaitGroup
	for n := 0; n < numWorkers; n++ {
		w.Add(1)
		go func() {
			for px := range c {
				m.Set(px.x, px.y, pixel(px.x, px.y, width, height))
			}
			w.Done()
		}()
	}

	for i := 0; i < width; i++ {
		for j := 0; j < height; j++ {
			c <- px{i, j}
		}
	}
	close(c)
	w.Wait()
	return m
}

We have a smaller number of goroutines, but definitely enough of them to distribute across all processors. This should be faster, right?

Well, never trust your instincts when it comes to performance analysis.

Let’s run it and see, first without the tracer.

$ time ./mandelbrot
./mandelbrot  10.31s user 3.22s system 422% cpu 3.201 total

Ok, so this is not better than creating a pixel per goroutine! Why? Well, time to trace.

$ time ./mandelbrot > workers.trace
./mandelbrot > workers.trace  30.86s user 13.88s system 383% cpu 11.660 total

$ go tool trace workers.trace
2017/10/23 11:49:20 Parsing trace...
2017/10/23 11:49:52 Serializing trace...
2017/10/23 11:50:02 Splitting trace...
2017/10/23 11:50:49 Opening browser

This is again incredibly slow, so clearly we’re logging many events. What are those events?

Again it seems quite good from far away, but when you zoom in it looks quite different.

Where is the contention coming from now? The runtime should be totally fine with eight goroutines, 2048 was not too many. Well, let’s go back to the menu where we clicked “View Trace” but instead let’s click Synchronization blocking profile. You’ll see a graph generated by our old friend pprof. In this graph we can see the contention due to synchronization primitives such as channels and mutexes.

So our goroutines spent almost 48 seconds blocked receiving from a channel! That’s, obviously, a problem.

Why is this? Our channel is being used as a way to communicate between the main goroutine sending pixels, and the workers. This happens 4 million times, which causes a lot of contention. How could be avoid most of this contention?

Buffered channels!

Buffered channels in this case will make most of the send and receive operations non blocking! You don’t trust me? You don’t need to. Let’s modify the program to use a channel with a buffer of a size that allows us to fit all of the pixels.

func createWorkersBuffered(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))

	type px struct{ x, y int }
	c := make(chan px, width*height)

The rest of the function is exactly as the previous one.

Will this make our program faster? Let’s see!

$ time ./mandelbrot
./mandelbrot  8.55s user 0.37s system 494% cpu 1.804 total

It is much faster than before but still not nearly as fast as creating one goroutine per column.

The tracer shows that we still have some contention, and pprof quantifies it to 613ms.

$ time ./mandelbrot > workers-buf.trace
./mandelbrot > workers-buf.trace  8.06s user 0.29s system 542% cpu 1.539 total

$ go tool trace workers-buf.trace
2017/10/23 12:04:51 Parsing trace...
2017/10/23 12:04:51 Serializing trace...
2017/10/23 12:04:51 Splitting trace...
2017/10/23 12:04:51 Opening browser

Compromises

Sending values through channels has a very low cost, but it does have a cost and we’re doing this over 4 million times in this program.

It seems like a good idea to limit this cost by creating fewer tasks. How can we even do that? Each task should be larger: let’s create a task per column.

func createColWorkers(width, height int) image.Image {
	m := image.NewGray(image.Rect(0, 0, width, height))

	c := make(chan int)

	var w sync.WaitGroup
	for n := 0; n < numWorkers; n++ {
		w.Add(1)
		go func() {
			for i := range c {
				for j := 0; j < height; j++ {
					m.Set(i, j, pixel(i, j, width, height))
				}
			}
			w.Done()
		}()
	}

	for i := 0; i < width; i++ {
		c <- i
	}

	close(c)
	w.Wait()
	return m
}

How much faster is this?

$ time ./mandelbrot
./mandelbrot  4.72s user 0.04s system 495% cpu 0.962 total

Pretty fast! And if we added a buffer to the channel, as shown in createColWorkersBuffered?

$ time ./mandelbrot
./mandelbrot  4.74s user 0.04s system 513% cpu 0.931 total

Just a tiny bit better.

Conclusion

So, it seems like creating one goroutine per column is the fastest option, but probably this changes given different image sizes. It is time to write benchmarks (they’re already written in the repo!), look at the traces and pprof data and make sensible and informed decisions.

We saw how pprof allows us to see how our program uses the CPU and how much locking contention exists. Pprof also provides a way to profile memory allocations which we didn’t cover. On the other side we saw the tracer, that allows us to have a very detailed view of what our program does, specially when our program doesn’t do much!

I hope you enjoyed this post, let me know what you think at @francesc and subscribe to #justforfunc for more content every two weeks!

Using the Go execution tracer to speed up fractal rendering was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

Problem statement

Imagine you’ve been given this program below and you want to extract all of the identifiers in it.

We should obtain a list containing main, fmt, and Println.

What is an identifier anyway?

In order to answer this we need to go a bit into language theory. Just a bit, do not worry.

Programming languages are defined, among other things, by a series of rules of what is a valid program. These rules look something like:

IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt | Block ) ] .

This rule tells us what an if statement looks like in Go. The "if", ";", and "else" pieces are keywords that help us figure out the structure of the program, while Expression Block, SimpleStmt, etc are other rules.

The set of these rules is called a language grammar. You can find all of them in the Go language specification.

These rules are not defined on the characters of the program, instead they’re defined on tokens. These tokens are atoms like if or else, but also slightly more complex kinds such as integers 42, floats 4.2, strings "hello", or … identifiers like main.

But how do we know that main is an identifier and not a number? Well, there’s also rules for this. If you read the identifiers section of the Go specification, you’ll find this rule:

identifier = letter { letter | unicode_digit } .

In this rule, letter and unicode_digit do not represent tokens; they’re classes of characters. So given all of these rules, it is pretty straight-forward to write a program that goes character by character and each time it detects a group of them that matches a rule it just “emits” a token.

So if we start with: fmt.Println it would generate the tokens: fmt as an identifier, ., and Println as an identifier. Is this a function call? Well, at this point we do not know, and we do not care. The only structure is a sequence letting us in what order things appear.

This kind of program that given a sequence of characters generates a sequence of tokens is called a scanner. The Go standard library comes with a scanner for Go programs in go/scanner. The kinds of tokens it generates are defined in go/token.

Using go/scanner

Ok, so now that we understand what a scanner is. How do we use it?

Reading arguments from the command line

Let’s start with this simple program that simply prints all of the arguments given when executing it. We’ll go from there.

Next we need to scan every one of the files given as arguments. To do this we will need to create a new scanner.Scanner and initialize it with the contents of the file.

Printing each token

Before we can call the Init method in scanner.Scanner we will read the file contents and create a token.FileSet holding a token.File per file we scan.

Once the scanner has been initialized we can call Scan and print the token we obtain. Once we reach the end of the file scanned, we will obtain an EOF (End Of File) token.

Counting tokens

Great, so we’re able to print all tokens, but we need to keep track of how many times we see each identifier, sort them by how many times we saw them, and print the top 5.

In Go, the best way to do so is to use a map where the key will be the identifier, and the value how many times it’s been seen so far.

Each time we see an identifier, we need to increment its counter. Finally, at the end, we convert the map into a slice of pairs, which we can sort and print.

Some code has been removed for clarity, but the full source code can be found here, in the justforfunc repository.

So what’s the most common identifier?

Let’s run the program giving with the contents of github.com/golang/go.

$ go install github.com/campoy/justforfunc/24-ast/scanner
$ scanner ~/go/src/**/*.go
 82163 v
 46584 err
 44681 Args
 43371 t
 37717 x

Ok, so the most used identifier is v, talk about short identifiers! Let’s count only those identifiers that are three characters or longer, by modifying the code above a bit:

for s, n := range counts {
	if len(s) >= 3 {
		pairs = append(pairs, pair{s, n})
	}
}

And run it again:

$ go install github.com/campoy/justforfunc/24-ast/scanner
$ scanner ~/go/src/**/*.go
 46584 err
 44681 Args
 36738 nil
 25761 true
 21723 AddArg

Nothing too surprising here, err and nil are present in basically every single program that does if err != nil. What about Args, though?

That’s a topic for a next episode.

Understanding Go programs with go/parser

Thanks

If you enjoyed this episode make sure you share it and subscribe to justforfunc! Also, consider sponsoring the series on patreon.

What’s the most common identifier in Go’s stdlib? was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

Previously in justforfunc

In a previous post, we used the go/scanner package in Go’s standard library to identify which was the most common identifier in the standard library itself.

Spoiler alert: it was v.

In order to get a somehow more meaningful list, we limited the search to those identifiers that were three letters long or more. This gave us err and nil, which we’ve all seen before in the (in)famous if err != nil { expression.

Variables: package vs local

What if I wanted to know which is the most common name for local variables? What about functions or types? In order to answer this question scanners fall short because they lack context. We know what tokens we saw before, but in order to know whether a var a = 3 is declared at package, function, or even block levels we need more context.

A package has many declarations, some of those declarations may be of functions which in time could declare local variables, constants, or even more functions!

But how do we find that structure from a sequence of tokens? Well, every single programming language has a set of rules that inform us on how to build such a tree from a sequence of tokens. This looks something like:

VarDecl = "var" ( VarSpec | "(" { VarSpec ";" } ")" ) .
VarSpec = IdentifierList ( Type [ "=" ExpressionList ] | "="  
                        ExpressionList ) .

The rules above tell us that a VarDecl (variable declaration) starts with a var token, followed by either a VarSpec (variable specification) or a list of them surrounded by parentheses and separated by semicolons.

Note: Those semicolons are actually added by the Go scanner, so you might not see them but the parser does.

If we start with a piece of Go code containing var a = 3, using go/scanner we could obtain the following list of tokens.

[VAR], [IDENT "a"], [ASSIGN], [INT "3"], [SEMICOLON]

The rules above help us figure out this is a VarDecl with only one VarSpec. Then we’ll parse an IdentifierList with a single Identifier a, no Type, and an ExpressionList with an Expression which is an integer with value 3.

Or, as a tree, it would look like the image below.

The rules that allow us to go from a sequence of tokens to a tree structure form a language grammar, or syntax. The resulting tree is called an Abstract Syntax Tree, often simply AST.

Using go/scanner

Enough theory for now, let’s write some code! Let’s see how we can parse the expression var a = 3 and obtain an AST from it.

This program compiles (yay!) but if you run you’ll see the following error:

1:1: expected 'package', found 'var' (and 1 more errors)

Oh, yeah. In order to parse a declaration we are calling ParseFile, which expects a full Go file therefore starting with package before any other code (expect for comments).

If you were parsing an expression, such as 3 + 5 or other pieces of code which you could see as a value you could pass as a parameter, then you have ParseExpr, but that function will not help with a function declaration.

Let’s simply add package main at the beginning of our code and see the AST we obtain.

And when we run it we get something a bit better … just a bit, though.

$ go run main.go
&{<nil> 1 main [0xc420054100] scope 0xc42000e210 {
        var a
}
 [] [] []}

Let’s print more detail by replacing the Println call by fmt.Printf("%#v", f) and try again.

go run main.go
&ast.File{Doc:(*ast.CommentGroup)(nil), Package:1, Name:(*ast.Ident)(0xc42000a060), Decls:[]ast.Decl{(*ast.GenDecl)(0xc420054100)}, Scope:(*ast.Scope)(0xc42000e210), Imports:[]*ast.ImportSpec(nil), Unresolved:[]*ast.Ident(nil), Comments:[]*ast.CommentGroup(nil)}

Ok, that’s better but I’m too lazy to read this. Let’s import github.com/davecgh/go-spew/spew and use it to print an easier to read value.

Running this program shows us pretty much the same as before, but in a much more readable format.

$ go run main.go
(*ast.File)(0xc42009c000)({
 Doc: (*ast.CommentGroup)(<nil>),
 Package: (token.Pos) 1,
 Name: (*ast.Ident)(0xc42000a120)(main),
 Decls: ([]ast.Decl) (len=1 cap=1) {
  (*ast.GenDecl)(0xc420054100)({
   Doc: (*ast.CommentGroup)(<nil>),
   TokPos: (token.Pos) 15,
   Tok: (token.Token) var,
   Lparen: (token.Pos) 0,
   Specs: ([]ast.Spec) (len=1 cap=1) {
    (*ast.ValueSpec)(0xc4200802d0)({
     Doc: (*ast.CommentGroup)(<nil>),
     Names: ([]*ast.Ident) (len=1 cap=1) {
      (*ast.Ident)(0xc42000a140)(a)
     },
     Type: (ast.Expr) <nil>,
     Values: ([]ast.Expr) (len=1 cap=1) {
      (*ast.BasicLit)(0xc42000a160)({
       ValuePos: (token.Pos) 23,
       Kind: (token.Token) INT,
       Value: (string) (len=1) "3"
      })
     },
     Comment: (*ast.CommentGroup)(<nil>)
    })
   },
   Rparen: (token.Pos) 0
  })
 },
 Scope: (*ast.Scope)(0xc42000e2b0)(scope 0xc42000e2b0 {
        var a
}
),
 Imports: ([]*ast.ImportSpec) <nil>,
 Unresolved: ([]*ast.Ident) <nil>,
 Comments: ([]*ast.CommentGroup) <nil>
})

I recommend spending some time actually reading this tree and seeing how each piece matches with the original code. Feel free to ignore Scope, Obj, and Unresolved as we’ll talk about those later on.

Going from AST to code

It is sometime useful to print an AST into the corresponding source code rather than its tree form. To do so, we have the go/printer package which you can easily use as a way to see what information is stored in the AST.

Executing this program prints the source code we parsed originally. It is now a good point to see how different values of the parsing mode affect what information is kept in the AST. Replace parser.AllErrors with parser.ImportsOnly or other possible values.

Navigating the AST

So far we have a tree that contains all of the information we want, but how do we extract the pieces of information we care about? This is where the go/ast package comes in handy (other than for declaring the ast.File that parser.ParseFile returns!).

Let’s use ast.Walk. This function receives two arguments. The second one is an ast.Node which is an interface satified by all the nodes in the AST. The first argument is an ast.Visitor which is also obviously an interface.

This interface has a single method.

Ok, so we already have a node, since the ast.File returned by parser.ParseFile satisfies the interface, but we still need to create an ast.Visitor.

Let’s simply write one that prints the type of the node and returns itself.

Running this program gives us a sequence of nodes, but we’ve lost the tree structure. Also, what are all of those nil nodes? Well, we should read the documentation of ast.Walk! Turns out the Visitor we return is used to visit each one of the children of the current node, and we end up by calling the Visitorwith a nil node as a way to communicate there’s no more nodes to visited.

Using that knowledge we can now print something that looks more like a tree.

The rest of the code in our program remains unchanged, and executing it prints this output:

*ast.File
        *ast.Ident
        *ast.GenDecl
                *ast.ValueSpec
                        *ast.Ident
                        *ast.BasicLit

What’s the most common name per kind of identifier?

Ok, so now that we understand how to parse code and visit its nodes, we are ready to extract the information we want: what are the most most common names for variables declared at package level vs those declared locally inside of a function.

We will start with a piece of code very similar to what we had in the previous episode, where we used go/scanner over a list of files passed as command line arguments.

Running this program will print the AST of each one of the files given as command line argument. You can try it on its own by running:

$ go build -o parser main.go  && parser main.go
# output removed for brevity

Let’s now change our visitor to keep track of how many times each identifier is used for each kind of variable declaration.

First let’s start by tracking all short variable declarations, since we know they are always local declarations.

For each assignment statement we’re checking whether the identifier name is _, which should be ignored, and whether this is the declaration point of the identifier. In order to do so we use the Obj field which keeps track of all the objects declared in a context.

If the Obj field is nil we know that the variable was declared in a different file, therefore it’s not a local variable declaration and we can ignore it.

If we run this program on the whole standard library we’ll see that the most common identifiers are:

  7761 err
  6310 x
  5446 got
  4702 i
  3821 c

Interestingly enough, v doesn’t appear at all! Are we missing any other ways of declaring local variables?

Counting parameters and range variables too

We’re missing a couple node types to have a more completely analysis of local variables. These are:

• function parameters, receivers, and named returned values.
• range statements.

Since the code to count a local variable identifier will be repeated all over let’s define a method on visitor instead.

For parameters and returned values we will have a list of identifiers. We also have the same for method receivers, even though they always have only one element. Let’s define an extra method for lists of identifiers.

Then we can use that method for all the node types that might declare local variables.

Great, let’s run this and see which one is the most common local variable name for now!

$ ./parser ~/go/src/**/*.go
most common local variable names
 12264 err
  9395 t
  9163 x
  7442 i
  6127 c

Handling var declarations

Let’s move into handling the var declarations. These are more interesting because they could be local or global, and the only way to know is to check whether they’re at the ast.File level.

To do so we’re going to create a new visitor per file which will keep track of the declarations that are global, so we can count the identifiers correctly.

To do so we’ll add a pkgDecls field of type map[*ast.GenDecl]bool in our visitor, and it will be initialized by a newVisitor function. We’ll also add a globals field tracking how many times an identifier has been declared.

Our main program will need to create a new visitor per file and keep track of the total results.

Ok, we just have one more piece of the puzzle to complete. We need to track the *ast.GenDecl nodes and find all the variable declarations in them.

For each declaration we will only count those that start with a token.VAR, therefore ignoring constants, types, and other kind of identifiers. Then, for each value declared, we’ll check whether it’s a global or local declaration, and count them accordingly and ignoring _.

The whole program is available here.

Executing the program will give us this result:

$ ./parser ~/go/src/**/*.go
most common local variable names
 12565 err
  9876 x
  9464 t
  7554 i
  6226 b
most common global variable names
    29 errors
    28 signals
    23 failed
    15 tests
    12 debug

So there you go, the most common local variable name is err, while the most common package variable name is errors.

Which one is the most common constant name? How would you find it?

Thanks

If you enjoyed this episode make sure you share it and subscribe to justforfunc and follow me on Medium or twitter! Also, consider sponsoring the series on patreon.

Understanding Go programs with go/parser was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

To those four incredibly dedicated fans, huge thanks and … are you OK?

Anyway, I thought it would be a good moment to see how the channel has evolved during 2017 and what videos have been the most successful.

First some stats

The channel is doing great. We recently passed 10k subscribers (which I celebrated with this video) and the number keeps growing! Look at these numbers, stat!

So without any more ado, let’s go with the top five videos of 2017!

#5: Unit Testing HTTP servers

This video was a fun one to do and I think it’s been very successful because it covers something people care about.

Testing HTTP servers is not necessarily easy and most people have no idea on how to use http.ResponseRecorder or even that it exists!

#4: Flappy Gopher

The first episode of a series of three videos that I started after attending GoLab.io in Florence early 2017. Why was this one successful? I mean … it shows you how to develop a Flappy Bird clone in Go!

The best thing of this episode is that I got many people sending me messages sharing their own projects. And the code was used in a program to teach children Go.

#3 A Text to Speech server with gRPC and Kubernetes

Was this episode the answer to “how many buzzwords can you include in a title”? We’ll never know … well, you’ll never know!

But the result is a fun video where I develop a distributed version of the say command available on Mac, using flite, Docker, Kubernetes, Go, and all of the other things cool kids do.

#2 The Context Package

I’ve received so many notes regarding this episode. Many many people tell me it’s the clearest introduction to the context package they’ve ever seen.

Maybe it’s because this episode was the result of a talk I gave four times before? Probably, but I want to believe it’s because I’m wearing the coolest t-shirt I own.

And last and definitely not least (because we’re counting down, so …)

#1 Go Tooling in Action

This video is the one that inspired me to create the channel. Its success is not really surprising as I keep on building on it by developing a full day workshop based on the materials I once developed for GOTO Chicago.

The video is so old that it doesn’t even have the justforfunc branding, since it didn’t exist yet!

What’s your favorite?

So what’s your favorite episode? Is it on this list or maybe it’s another one of the 26 episodes I’ve released so far!

Let me know on twitter @francesc and send any feedback or suggestions for the channel to form.justforfunc.com.

Thanks (and super thanks to my patrons!)

Thanks to all the subscribers for an amazing 2017, and to my patrons for allowing me to improve the recording material (now that I don’t work for Google anymore).

You can become one of my patrons on patreon.com/justforfunc, and in exchange you’ll have my eternal gratitude!

The justforfunc 2017 top 5 was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog post is complementary to episode 26 of justforfunc which you can watch right below.

Everybody that has written some Go knows about channels. Most of us also know that the default value for channels is nil. But not many of us know that this nil value is actually useful.

I got this same question on twitter, from a developer learning Go, wondering whether Go nil channels existed just for completeness.

It does makes sense to wonder whether they’re useful, as their behavior seems to indicate otherwise.

Given a nil channel c:

• <-c receiving from c blocks forever
• c <- v sending into c blocks forever
• close(c) closing c panics

But I still insist they are useful. Let me introduce a problem whose solution seems obvious at first, but it is actually not as easy as one might think and actually benefits from nil channels.

Merging channels

Your mission, should you choose to accept it, is to write a function that given two channels a and b of some type returns one channel c of the same type. Every element received in a or b will be sent to c, and once both a and b are closed c will be closed too.

An auxiliary function

Before we start, let’s write a function that will help us test our solution. This function returns a channel that will eventually receive, at random intervals, all of the given values and finish by being closed.

This function creates a channel, starts a new go routine that sends values to the created channel, and finally returns the channel.

This is pretty common pattern when dealing with channels, so make sure you understand how it works before you continue reading.

Let’s get started

Since we don’t really have a preference over a or b we’re going to avoid creating a preference by choosing on which channel we should range first. Let’s instead keep the symmetry and use an infinite loop and select over both channels.

This looks pretty good, let’s write a quick test and run it.

This should print 1 to 8 in some order and end successfully. Let’s see what happens.

> go run main.go
1
2
3
4
5
6
7
8
0
0
0
0
0
0
0
😱

Ok, so clearly this is not good because the program doesn’t ever finish. Once it has printed the values from 1 to 8 it starts printing zeros forever.

Handling closed channels

What happens when we receive from a closed channel? We get the default value of the type of the channel. In our case, the type is int so the value is 0.

We could check for channels being closed by comparing to zero, but what if one of the values we received was a zero? Instead we can use the “value comma ok” syntax:

v, ok := <- c

When using this syntax ok is a boolean that will be true for as long the channel is open. Knowing this we can avoid sending superfluous zeros into c.

We should also stop iterating at some point … so let’s keep track of when both channels are closed too.

This looks like it might work! Let’s run it.

> go run main.go
1
2
3
4
5
6
7
8
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
main.main()
        /Users/francesc/src/github.com/campoy/campoy.cat/site/static/code/nilchans/main.go:13 +0x186
exit status 2

Ooops, we forgot something. What could that be? Well, we can see that there’s only one go routine running and it’s blocked on line 13. That line is:

for v := range c {

Can you see what the problem is? Well, a range statement iterates over all the values in a channel until the channel is closed. But who is closing the channel?

We forgot! Let’s add a defer statement in our go routine to make sure the channel is closed eventually.

Note that the defer statement is inside of the anonymous function called in a new go routine, rather than inside of merge. Otherwise c would be closed as soon as we exited merge and sending a value into it would panic.

Let’s run it and see what happens.

> go run main.go
1
2
3
4
5
6
7
8

This looks great … but is it?

Busy loops

The code we wrote so far is pretty good. It is functionally correct, but if you deployed this in production you might end up running into performance troubles.

In order to show you where the problem is, let’s add a bit of logging.

Let’s run it and see what happens.

> go run main.go
2
3
4
5
6
7
8
a is done
2018/01/14 20:47:22 b is done
... 😱
2018/01/14 20:47:23 b is done
2018/01/14 20:47:23 a is done

Uh oh! It seems once a channel is done we keep on iterating non-stop!

It does make sense after all. As we saw at the beginning reading from a closed channel never blocks. Therefore the select statement will block as long as both channels are open until a new element is ready, but once one of them closes we will iterate and waste CPU. This is also known as a busy loop, and it’s not good.

Disabling a case in a select statement

In order to avoid the busy loop describe previously we would like to disable a part of the selectstatement. Concretely, we’d like to remove case v, ok := <- a when a is closed and similarly for b. But how?

As we mentioned at the beginning, receiving from a nil channels blocks forever. So to disable a casereceiving from a channel, we can simply set that channel to nil!

We can then stop using adone and bdone and instead check for a and b being nil.

Ok, hopefully this will avoid unnecessary loops. Let’s try it.

> go run main.go
2
1
4
3
6
5
8
7
b is done
a is done

The code for the final solution is on GitHub.

Victory!

This is just one of the many concurrency patterns that can benefit from nil channels. Have you used nil channels to solve some other problems? Share your story! You can get in touch with me on twitter or simply dropping a comment here.

And you might wonder … how dow e merge more than two channels?
Well, wonder no more and go read the next episode that covers exactly that!

Two ways of merging N channels in Go

If you enjoyed this episode make sure you share it and subscribe to justforfunc! Also, consider sponsoring the series on patreon.

Why are there nil channels in Go? was originally published in justforfunc on Medium, where people are continuing the conversation by highlighting and responding to this story.