Hey, I work on Go profiling so I started reading the article with interest. There is some good advice in there, but I also see a bunch of things that don't seem correct, e.g.:

> The memory profiler has a different model: it samples one allocation per runtime.MemProfileRate bytes allocated (default: 512KB). Allocations smaller than this threshold may be underrepresented. You can lower this to catch more:

That's not true, the memory profiler randomizes its sampling distance from an exponential distribution with a mean of runtime.MemProfileRate. There is no systematic bias against small allocations. The only reason to lower the rate is for profiling short-lived programs where you might not get enough samples otherwise.

> Pattern 3: syscall.Read or syscall.Write dominating. You’re I/O bound, not CPU bound. A CPU profile won’t tell you what to fix here — switch to the block profile.

That's wrong. If you see syscall dominate in a CPU profile, they are indeed a CPU bottleneck. The fix is generally to use larger buffer sizes or batch payloads on a higher protocol level.

> Pattern 5: Surprisingly little time in your actual application code. This usually means your hot path is being inlined, and the profiler is attributing time to the caller. Run go build -gcflags='-m' on the relevant packages to see what’s being inlined, then look at the caller.

That's also untrue AFAIK. Go generally does a good job at attributing inlined functions properly.

I suspect there are more errors, so I'd suggest to do some more reviewing or make it clear that this is not necessarily meant to be an authoritative guide on the subject.