Austin Clements

This is really exciting. Thanks for doing all of this work. > The benchmarks from runtime. There are many slowdowns in these benchmarks, some quite significant. Do you understand the...

Thanks for the detailed breakdown of the performance losses! My take is that there are two things that need to happen on that front: - Work on improving the small...

Stepping back, I think there are three high-level potential concerns to address with this: **Incremental resizing.** We've already been discussing this above. :) **DoS prevention.** Currently, Go maps have fairly...

> Indeed. We can add some new benchmarks to it. I feel like adding the new one into https://github.com/zhangyunhao116/gomapbench first and then migrating some of it into the runtime is...

I asked @mcy for useful references to learn more about SwissTables and he pointed me to these: - [Matt Kulukundis's CppCon 2017 talk](https://www.youtube.com/watch?v=ncHmEUmJZf4) is a good overview. It also has...

I totally agree with @josharian . Making sure there's a workable incremental growth story is higher priority than SIMD optimizations. > or a little more for unaligned groups I have...

Reopening because this is still happening. I'm not sure if we have enough extra data to do anything about it yet.

There's discussion in #51256 that's relevant to fixing these nosplit stack overflow issues at a deeper level, though we probably want a shorter-term fix for this.

The discussed fix on our side is to increase the stack guard for -race builds. We *might* be able to do this in `objabi.stackGuardMultiplier`, since `-race` applies to the whole...

@thanm recently ran into a problem where it seems recent Windows C toolchains produce binaries that don't run on the Windows 2008 (≈ Windows 7) builder, which is further support...