8 ms·

The arena experiment is on indefinite hold: > Note, 2023-01-17. This proposal is on hold indefinitely due to serious API concerns. https://github.com/golang/g

• truth_seeker 1y ago
  >Note that the best-case scenario is the elimination of the overheads above to 0, which is at most ~10% in these particular benchmarks. Thus, it's helpful to consider the proportion of GC overhead eliminated relative to that 10% (so, 7% reduction means 70% GC overhead reduction). Wow. amazing to see of off-heap allocation can be that good https://go.googlesource.com/proposal/+/refs/heads/master/design/70257-memory-regions.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
  • pjmlp 1y ago
    Meanwhile Java and .NET have had off-heap and arenas for a while now. Which goes to show how Go could be much better, if being designed with the learnings of others taken into account. The adoption of runtime.KeepAlive() [0], and the related runtime.AddCleanup() as replacement for finalizers are also learnings from other languages [1]. [0] - https://learn.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.gc.keepa... [1] - https://openjdk.org/jeps/421 https://openjdk.org/jeps/421
    • truth_seeker 1y ago
      What a coincedence ! :) Recently used MemorySegment in Java, it is extremely good. Just yesterday i implemented Map and List interface using MemorySegment as backing store for batch operations instead of using OpenHFT stuff. Tried -XX:TLABSize before but wasnt getting the deserved performance. Not sure about .NET though, havent used since last decade.