sync.Pool is not useful for long lived objects - which the op implies to me
> On Jul 21, 2020, at 9:11 PM, tokers <zchao1...@gmail.com> wrote: > > And maybe the reuse mechanism (e.g. sync.Pool) is good for you. >> On Tuesday, July 21, 2020 at 1:35:14 AM UTC+8 netconn...@gmail.com wrote: >> I have an application where I will be allocating millions of data >> structures, all of the same size. My program will need to run continuously >> and be pretty responsive to >> its network peers. >> >> The data is fairly static, once allocated it will rarely need to be modified >> or deleted. >> >> In order to minimize the garbage collection scanning overhead, I was >> thinking of allocating large blocks on the heap that were a fixed size that >> would hold 20K or so elements >> and then write a simple allocator to hand out pieces of those blocks when >> needed. Instead of having to scan millions of items on the heap, the GC >> would only be scanning 100 or so >> items. >> >> Sound reasonable? Or does this 'go' against the golang way of doing things? >> >> F > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6eff37cc-9d83-4735-8530-8df40b4e72d5n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/97B80269-9F83-4166-AF99-0F1387B47E63%40ix.netcom.com.
