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.

Reply via email to