For long running applications, what is the recommended usage of the memory.Allocator struct? Is it generally the case that people use a single instance of the struct like a singleton pattern? There's a singleton instance which is declared as part of the library which you can use via memory.DefaultAllocator. In the vast majority of cases that will be sufficient. You only really need to use a specific allocator or have multiple allocators if you are doing something special with your allocations and want to distinguish between the default Go memory allocation and something else. One example would be the memory.CGoAllocator which is accessible by using the ccalloc tag when building and requires having libarrow.so accessible to link against. You would then likely create a CGoAllocator for when you want to allocate memory in C as opposed to memory managed by the Go garbage collector from the DefaultAllocator, etc.
There's other uses too such as using memory-mapped IO or other shared memory type things, but like I said, unless you're in the special case where you really need that level of manual control over your memory allocations, which is few and far between, my recommendation is to just use the DefaultAllocator. ________________________________ From: James Van Alstine <[email protected]> Sent: Tuesday, December 14, 2021 22:18 To: [email protected] <[email protected]> Subject: [Go] Memory Allocator Usage For long running applications, what is the recommended usage of the memory.Allocator struct? Is it generally the case that people use a single instance of the struct like a singleton pattern? For long running applications, what is the recommended usage of the memory.Allocator struct? Is it generally the case that people use a single instance of the struct like a singleton pattern?
