5

I'm looking at using Go (aka golang) for a project (a SQL database, but that mostly doesn't matter here) where performance is critical, but under low load the primary bottleneck will be I/O to disk. In this case, I think Go would be great!

Under high load or while hitting cache a lot, CPU and memory utilization will increasingly become bottlenecks, and I'm worried that Go could make the high-end of the performance spectrum significantly lower than what C/C++/D might provide.

Can anyone with experience working in Go give some insight into how quickly that bottleneck is reached (networking applications are subject to the same bottleneck, typically) and what you can do to relax it in Go other than rewriting the bottleneck in a faster language?


Note my question was sufficiently different that I asked it anyway after reading related question:

I have a specific application I'm asking about, and I've limited my concerns to performance (not usability, library support, development tools, etc).

0

3 Answers 3

1

What was said in another answer. I'll add that in garbage collected languages it pays to write the code in a way that's easy for the collector to work with.

Go also has a profiler you can use when experimenting with different code samples. You can also look at Doozer (written by a top Go coder) and sample projects (link below) for ideas on how to squeeze the most performance out of go.

https://code.google.com/p/go-wiki/wiki/Projects

1

I come to Go as a mostly "dynamic languages" programmer.

With that said it seems like you get pretty close to C performance as long as you take care to do the same things you'd do in a fast C program, avoid excessive allocations, pick your algorithms, etc.

Go will make some of that much easier to do whole staying bug-free, so given the same development time my estimate is that your performance can be similar, too. (Buy you will definitely have more fun).

0

From the Go Nuts mailing list, https://groups.google.com/forum/#!forum/golang-nuts, and my own practice, I've picked up a few things:

  1. There are ways to reduce the amount of garbage created, so less has to be collected, improving performance.

  2. The code generator is still undergoing improvement and is nowhere as mature as gcc, for example.

  3. The ease of parallel programming on multi-cpu servers should, in the large-enough case, make a golang implementation faster. Also, it can actually simplify program logic. Few other concurrency systems can claim that.

  4. Some of the Go standard libraries are better than others. This implies that the others are worse.

  5. The networking code is very good. However, the netchan package was deprecated as too intricate.

  6. You'll have a choice of representing character/string data as byte arrays or as strings. Prefer byte arrays for performance and database storage. Prefer strings for user displays and file names, and to leverage utf8. All Go strings are utf8, byte arrays often are utf8, and arrays of ints are used for utf-32. Converting from one to the other requires an allocation-and-copy, and generates garbage (for later collection).

  7. Generally, pass strings and/or byte arrays as slices, which is like a reference, but has substring semantics.

  8. Go strings are immutable but you can iterate through the characters, which means if it's utf8 data in the string, each iteration can consume more than one byte. Usually that's a great help.

  9. The profiler is essential, I easily sped up a program that used 17 minutes of cpu time in 17 minutes, down to a few seconds. The benchmarking facility provides finer grained information.

  10. Compilation is fast and there is no VM to startup, so compile-and-test is fast.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.