tl;dr someone wrote some code that showed me how to speed up a game, so I'm happy.
If you're a Pythonic App Engine programmer, then you know that AppStats and NDB make your life a lot easier. AppStats watches your running program and gives you pretty whaddyacallem-Gantt-charts-or-something showing where the time goes. Since your program's time probably goes towards inefficient data storing, the next thing you want is NDB, which lets you write your program in a sensible way and automagically stores things efficiently. But golang App Engine doesn't have those things, right? Well, hang on.
Matt Jibson wrote an AppStats for Go. As with the Python AppStats, you can tweak your program a little, get your program to do that one slow thing, then look at a chart showing where the time went.
I just used it to speed up the way that The Octothorpean Order puzzlehunt game website thing checks puzzle answers. In general, the program behind The Octothorpean Order is written more to be readable than fast. It's a side project; if I can't quickly understand the code picking it up after having set it aside for a couple of weeks, then I'm in trouble. And for the most part, that's fine. Not-fast ain't necessarily slow. But the answer-checking function was slow. Thanks to AppStats, I could see which of my readable-instead-of-fast bits actually mattered, and then rewrite that part.
Those slow parts were, of course, in the data-storing things. (Did the team solve the puzzle? Did they unlock new puzzles? If so, let's store the fact that they unlocked those puzzles, one… puzzle… at… a… time (instead of all at once).) I reworked just enough of my code to fix the worst of these. But if I were starting over today, I'd look into the same author's Goon library—which ports NDB's auto-caching features to Go. (It doesn't have Python NDB's nice asynchronous support; if I were a better Go programmer, maybe I'd know whether it was easy to fake this with goroutines or impossible because of the lack of async golang datastore APIs and multi-threaded goroutine... Anyhow.)
When explaining why he wrote these things, Jibson said The two killer features of the python runtime on app engine are NDB and appstats. I have been refusing to make a serious app with the go runtime because of this lack. It sounds kinda breathless, but he's basically right; you need a way to find out where your program's slow or there's a temptation to optimize prematurely until you're wading in code spaghetti all the time; caching-I-don't-have-to-think-about solves many problems. I'm sure glad he ported AppStats.
