pixelherodev commented on PR #322: URL: https://github.com/apache/arrow-go/pull/322#issuecomment-3500490010
> @lidavidm @pixelherodev what would you both think about a build flag that would make the retain/release calls no-ops and solely use `AddCleanup` so that a consumer could essentially "opt-in" if they aren't concerned about the non-deterministic nature of the GC? Having the option to turn off retain/release sounds good to me. > I assume the Go compiler will inline/dead-code-eliminate calls properly so that the overhead doesn't increase. We've used that internally for similar behavioral switches; IIRC we checked and there's no asm generated when it's disabled. One other thought, though: if we're already using memory.DefaultAllocator, the Go allocator, Free is a no-op. We shouldn't even need the cleanups, _or_ the release/retain. IMO it almost makes more sense to move the AddCleanup logic _into memory.Allocator_, and not invoke it at _all_ for the Go allocator. That, combined with Retain/Release being disabled, would allow users of the _default allocator_ to not be paying overhead for special cases - does that design make sense? > if they aren't concerned about the non-deterministic nature of the GC I'd like to address this a bit more though, too: what _are_ the cases where this is a problem? In my testing, the cost of Retain/Release is often strictly higher than a GC interruption would be anyways, and that's with pretty heavy memory allocations (which I'm still working on cutting down :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
