You could create an array per object type (which would be the aggregate underlying array of your slices) and use a sync.Pool for each type as the previous post mentions.
On Saturday, July 9, 2016 at 8:40:15 AM UTC+2, Arthur wrote: > > the program need parser SQL, and generate the AST node allocates many > temporary object. > after compile, all AST objects can be recycled. > pprof show parser take 14% of the whole object allocation, and 40% CPU > time is waste on GC scan related. > GC is good, but not free. > > 在 2016年7月9日星期六 UTC+8下午2:25:05,Chad写道: >> >> Create an array instead. But with the progress of the GC algorithm... not >> sure you should encounter such GC pressure. >> >> On Saturday, July 9, 2016 at 7:11:49 AM UTC+2, Arthur wrote: >>> >>> my program allocates many different kinds of small object, and that >>> gives GC a lot pressure. >>> so I wan't to make a big slice and split object from it manually. >>> >>> block = make([]byte, 30*1024) >>> myObj := (*myObjType)(unsafe.Pointer(&block[offset])) >>> >>> I write a simple allocator to do it, but I meet strange panic. >>> so my question is, can't go alloc custom objects from byte slice's >>> memory address? >>> >> -- 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. For more options, visit https://groups.google.com/d/optout.