The first two posts in this series were about collecting data: CPU and wall-clock samples from a signal handler, and heap samples from inside the allocator. Both produce a pile of stack traces with counts attached.
In Part 1 I wrote about sampling where a Python program spends its time. Memory usage is the other half of the question. Like time profiling, you can trace every allocation (which is what the standard library tracemalloc does), but this is far too expensive to leave enabled in a production server, so it usually gets enabled after the problem appears, on a process that no longer contains the interesting state.
I was working on a profiling system at work and became jealous of Go. The Go runtime has CPU and heap profilers built into the language. You can attach to a running production service, pull a profile over HTTP, and explore it with go tool pprof — flame graphs, call trees, diffs between two snapshots — without restarting anything or deciding in advance that today was the day you would need a profile.
in Games on Games, Game-theory, Go, Machine-learning
Over the holidays I played Exploding Kittens with my family for the first time.The player who draws the “exploding cat” card loses unless they can defuse it; cards can skip turns, draw from the bottom of the deck, reveal the next few cards, shuffle the deck, or force a card to change hands. There are expansion decks with additional cards and unique mechanics. It is a fun game and can be played with almost any number of players. I lost, and in typical fashion, set out to solve it. The result is AlphaCats.