For some added fun, also see go.dev/cl/715362, wherein I discover that VPCOMPRESSQ is horrifically slow on AMD Zen 4, but only with a memory destination.

And thanks to @lemire.bsky.social for writing about this, which made this much faster to track down!

I can certainly see how that would be frustrating. I referenced the closed-as-dupe issues in the new issue as well, thanks for pointing them out!

Filed github.com/golang/go/issues/75967.

Not to speak for the person who closed it, but it's probably still accurate that nobody plans to work on it in the near future. However, opening a proper the feature request or proposal and leaving it open seems reasonable.

There might just be a misunderstanding here. That issue was about naming a flag that didn't end up making it in. In that context, it makes sense to close the issue, I think.

I'd love to hear from folks about your experiences. Do you use execution tracing often. If not, is it due to lack of need, lack of documentation, missing information, tooling issues, etc?

Nice!!

Please try it... 🙏 Instructions here: github.com/golang/go/is...

is that a pen plotter drawing by Michael Fogleman, maybe? (www.michaelfogleman.com/plotter/)

Agreed. It's already a niche tool and having it actually cause a real problem is likely even rarer than that.

It could be useful to us working on std, I guess?

The sketch doesn't currently report issues related to the tiny allocator, but yeah, I'm thinking that such a GODEBUG could.

If such a debugging mode would be useful, what would be the most helpful information for debugging? Stack trace where the finalizer was applied? The object's type?