Settings

Theme

Generic Freelist Allocator for Go

pkg.go.dev

10 points by Snawoot a year ago · 3 comments

Reader

nasretdinov a year ago

I've used this idea to speed up AST parsing: https://github.com/z7zmey/php-parser/issues/21

By just reducing cost of doing allocations (but still allocating the same number of structs) on some of the hot paths it sped up making of the AST tree by 1.5x

If you can use this approach for the entire parser I imagine the gains would be much more significant

  • SnawootOP a year ago

    That's great! I see you use `sync.Pool`, which is way safer alternative. However, I wasn't able to secure much of performance gains for linked list benchmark using sync.Pool. It's not even clear how much objects it will contain ready to go. On the other hand, sync.Pool docs suggest to implement own free list for small short-living objects. I wonder what do they mean and how it should look like?

    • nasretdinov a year ago

      I actually only use sync.Pool to allocate large chunks at a time, so the cost of sync.Pool calls is minimal. The main benefit comes from allocating (and freeing) the big chunk instead of individual structs, without having to worry about object lifetimes.

      Correction: no, looks like I do indeed call it each time. Well, it's still more efficient I guess :))

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection