[deckarep]

Awesome blog post Ben! Question: how did you come up with your list of opcodes?

I ask because while some opcodes are obviously needed others as not so obvious and coming up with a balanced instruction set is somewhat difficult design problem.

[benhoyt]

Good question. A bit of experience, some guesswork, and a lot of testing and benchmarking along the way. I separated out global and local opcodes originally because I wanted individual variable accesses to be fast (why do at runtime what you can do at compile time). As I mention in the article, originally I had all the builtin functions as separate opcodes, but that was slower due to the sheer number of opcodes and Go's current binary tree approach to "switch". I also used Go's profiling tools a bunch to see where the hotspots where. I'm sure there's significant room for improvement, but it's hard, because sometimes when you improve one benchmark, something else suffers.

[ternaryoperator]

What tools did you use for timing and benchmarking beyond the tools included in the go distribution?

[benhoyt]

Just the Go benchmarking tools built into "go test", as well as a couple of scripts of my own just using "time ./goawk 'BEGIN { ... test script ... }'" and that kind of thing. Nothing fancy!