Nanolog: Super Fast Logging for Go

I’ve released a new package called nanolog! Nanolog is super fast, as low as 70ns to log a line, and works with concurrent loggers. It uses a somewhat different model than most people are used to for the API; you can think of it like prepared statements for logging. It is currently at version 0.1.0. This package was inspired by a project of the same name for C++. Why? Because. Read On →

A Foray Into Go Assembly Programming

This blog post started last August when I was integrating the Spectator PercentileTimer concept into the metrics library in Rend so we could get better cross-fleet latency percentiles. As a part of doing this, I had to port the code that selects which bucket (counter) to increment inside the PercentileTimer distribution. A PercentileTimer is implemented as a large array of counters, each of which represent a bucket. They are incremented whenever the observation lands in that bucket. Read On →

Goroutree: A tree-based set made of coordinating goroutines

This is a cross-post of my blog post for the GopherAcademy Advent 2016 series. It’s replicated below in its entirety. This was one of those projects that sat in the back of my mind for quite a while. It was destined to join the many others in my side project graveyard unless I had a good reason to finish it, like a date for a blog post. This post is an explanation and exploration of the goroutree data structure. Read On →

10k Concurrent Connections

After my recent appearance on the Go Time podcast I thought it would be fun to write a post on a few performance bits in Rend, the software project I hack on at work. This topic comes up frequently enough that I felt I should write about it. The c10k problem has many solutions already. This is just my take. Fortunately for people in 2016, handling 10 thousand concurrent connections is not really all that difficult anymore. Read On →

Working With Forks in Go

This been written about before in the Go universe, but I felt it was worth reviewing as it has come up many times in the Go slack (invite link). When developing on a separate remote from the original in Go, there is a common point of confusion when a developer forks on Github (for example) and then proceeds to go get the fork. This places the fork in the wrong spot in their $GOPATH and none of the imports work. Read On →

Managing Syscall Overhead with crypto/rand

The overhead of using secure random numbers can be a headache if the generation of those numbers is in your server’s critical path. In this post, I’ll look at a couple of techniques to bypass the overhead of generating random numbers in a Go program and make a recommendation on what method to use. Consider an application that needs to generate a nonce for each request which is also I/O bound, meaning it does more waiting on I/O than anything else. Read On →

How to Block Forever in Go

Let me count the ways There seems to be quite a few ways to block forever in Go. This post is part code golf and part practical advice. All of the code below is simply to find a way to block the current goroutine from progressing while still allowing others to continue. The versions that block forever will actually cause a panic saying that all goroutines are asleep, but the ones that “busy block” will just time out on the playground. Read On →

Locking in crypto/rand

As a followup to my previous post detailing my journey through some profiling of the math/rand package, I wanted to write about the crypto/rand package. A couple people have suggested that I take a look at that instead of worrying about locking in math/rand. On the surface, it’s an easy interface that fills a byte slice full of cryptographically secure random data. I modified the rand_default.go program from the previous post to create a new program to pull data from crypto/rand instead of math/rand. Read On →

The Hidden Dangers of Default Rand

This post is based on a real-world problem that I faced when I was developing a load generator program for work. I looked through my code carefully to make sure that there weren’t any bottlenecks in the design or bugs in the implementation, but didn’t find anything explicitly wrong. I did some profiling after that and found something very interesting: deep down in the rand package was a lock that was taking up the majority of the time in the application. Read On →

An Analysis of the Top 1000 Go Repositories

This analysis was done from copies cloned on January 2, 2016 early morning Pacific Time. Code organization Most code is a library, so the code is organized as either .go files under the main repo, or as .go files under sub-directories. Many people also organize their code under a sub-directory, like /src, /lib/, /go/, or /pkg/. I can’t manually inspect all of the repositories, but those I did check are apps written in go rather than libraries. Read On →