Allocating lots (e.g. a million) objects on the heap

[netconn...@gmail.com]

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

[Jan Mercl]

Check https://godoc.org/modernc.org/memory, maybe it can be used in this scenario. Note, using the package concurrently from multiple goroutines requires coordination, like with a mutex.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0be7d132-71d6-4ff9-a8eb-ca09a94fafeao%40googlegroups.com.

[Robert Engels]

All you are doing is replicating manual memory management. If you are going to do that just use CGo with malloc & free so you will have decent debugging. 

If not, don’t do this at all and let the GC do its work (but Go lack of a generational GC might be an issue here). 

On Jul 20, 2020, at 12:47 PM, Jan Mercl <0xj...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vn%2Bg8Yb9%3DX-K_95%3Dt6kQ3gr43kpj9JMwxRk3FMEv00Rw%40mail.gmail.com.

[jake...@gmail.com]

Do the data structures contain pointers? If not, I seem to strongly recall that the GC does not have to scan slices when the objects contain no pointers. Perhaps someone with in-depth knowledge of the GC can confirm or refute that. If that is the case, then large slices should not be a burden on the GC, and would be the simplest solution.

[tokers]

And maybe the reuse mechanism (e.g. sync.Pool) is good for you.

[Robert Engels]

sync.Pool is not useful for long lived objects - which the op implies to me

On Jul 21, 2020, at 9:11 PM, tokers <zcha...@gmail.com> wrote:

And maybe the reuse mechanism (e.g. sync.Pool) is good for you.

--

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...@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.

[Amnon]

Try a naive solution, and see if it is good enough, 
before optimising.

[Jesper Louis Andersen]

On Mon, Jul 20, 2020 at 7:34 PM <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.

I'd recommend quantifying "pretty responsive" in this case. Chances are you can get away with not doing anything at all, depending on the requirements.

Go currently employs a concurrent garbage collector, which typically enjoys very small pause times (less than 500 microseconds). You might be able to use it to fulfill your goals, without having to resort to extra work. That said, the more pointers your data have, the more work has to be done to scan, so the structure of your data matters as well. Knowing a bit about that data would help since you can often structure it in ways that are efficient.

So the TL;DR version is: the work you have to do is exponential to how efficient you have to do it. Chances are you have to spend a lot of time to optimize. So make sure you have a need for optimization, before you start doing it.