Rewriting the Buildbox Agent in Go(buildbox.io) |
Rewriting the Buildbox Agent in Go(buildbox.io) |
Part of my curiosity here is that Go's GC isn't yet very good, so I'm assuming that something about typical Ruby patterns results in a lot of not-garbage on the heap, but I'm also wondering if this could simply reflect bad design.
In Go, it would be very awkward to use map[string]interface{} everywhere, whereas that is VERY common in ruby. sizeof(map) > sizeof(struct).
Ruby stores all of the source of all of the files at runtime in memory, and IIRC, the AST nodes themselves are still run through the GC. If you have a load of dependencies, this is "fun".
I believe everything in Ruby is heap-allocated. The profiling tools for Ruby can help you identify "leaks", by telling you the classes of live objects. In go, you can get a dump of the number of allocations attributable to each line of code.
Ruby has the interesting quirk that every interned string (symbol) is retained forever.
With Go, you can set a quick flag that will force the GC to run after the percentage of new allocations exceeds a certain ratio. With ruby, you can tweak the GC with certain compile and environment flags, but this is not regularly practiced by the community and is ruby version dependent.
https://github.com/buildboxhq/buildbox-agent/blob/master/bui...