Felix Geisendörfer

@[email protected]
706 Followers
89 Following
40 Posts
Felix GeisendörferApr 3, 2023

New Blog Post: 8 Unexpected Profiling Use Cases Beyond Performance Optimization

https://blog.felixge.de/8-unexpected-profiling-use-cases-beyond-performance-optimization/

8 Unexpected Profiling Use Cases Beyond Performance Optimization

Profiling is often associated with performance optimization, but it has many other valuable use cases. Here are 8 of my favorites: 1. Detect Workload Shifts: Handler frames get wider when they get more work. 2. Detect Data Nesting: Frames often get deeper when processing more nested data. 3. Detect Dead

Felix Geisendörfer
Felix GeisendörferApr 2, 2023
dominikhMar 30, 2023

I have released v0.1.0 of Gotraceui, the efficient frontend for Go execution traces. It is my latest project and an attempt at bringing Go's traces to the masses.

Please check it out at https://github.com/dominikh/gotraceui/releases/tag/v0.1.0

Release Gotraceui v0.1.0 · dominikh/gotraceui

This is the first release of Gotraceui, the efficient frontend for Go execution traces. It is the culmination of nine months of work and over 700 commits. The attached PDF is a manual explaining mo...

GitHub
Show threadFelix GeisendörferMar 11, 2023

💐RIP gentraceback
2010-03-23 - 2023-03-10

Thank you for all the unwinding.

Show threadFelix GeisendörferMar 11, 2023

So again, 👏🏻 to Austin Clements for this incredible work, but also
@prattmic for some fantastic review comments.

The people working on the Go runtime team are really incredible. ❤️

Show threadFelix GeisendörferMar 11, 2023

If you need a comparison (or laugh), feel free to look at my pathetic attempt from last year to do the same refactoring 🤣.

I spent a week on it and produced 54 chaotic patches that didn't even get me half way to a full iterator API.

https://github.com/felixge/go/pull/4

refactor gentraceback into iterator style by felixge · Pull Request #4 · felixge/go

The goal is to refactor gentraceback to use a more high-level iterator API internally. E.g. something like this: itr := newTracebackIterator(...) for n := 0; n < max; { if !itr.Next() { break }...

GitHub
Show threadFelix GeisendörferMar 11, 2023

I've still skipped over many other aspects, such as designing a nice API, dealing with inlining, etc. - but hopefully you can see why this is really gnarly stuff to be hacking on.

So now look at these 17 patches again. It's a real work of art 🙇🏻‍♂️.

https://go-review.googlesource.com/c/go/+/472956

Show threadFelix GeisendörferMar 11, 2023

Last but not least: Breaking up such a complex refactoring is necessary in order to give somebody a chance to review it.

And this makes everything harder. What if you're 10 patches in, and you notice a mistake in patch 3? It's possible, but very hard to make these kind of edits.

Show threadFelix GeisendörferMar 11, 2023
Next up are the build bots: Assuming you've got something work on your local machine, there is a decent chance you've broken things on another OS or architecture. You'll spend lots of time debugging these kind of failures.
Show threadFelix GeisendörferMar 11, 2023
Secondly you're not really writing Go. You're writing "runtime code" that has to be signal safe. The rules for this are incredibly subtle, and you'll quickly learn about write barriers and how the compiler will refuse to build things when you introduce them into this code.
Show threadFelix GeisendörferMar 11, 2023

Now let's explore why it's so difficult to refactor this function. The first reason is that it's insanely difficult to debug this code when you break it.

It'll produce the most cryptic panics, crashes, corruptions and issues you can imagine.