[jira] [Commented] (THRIFT-3864) Reuse heap allocations of handler results

["James E. King, III (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15351616#comment-15351616 ] 

James E. King, III commented on THRIFT-3864:
--------------------------------------------

If large block allocation or garbage collection is not efficient in golang, that sounds like a language issue.  One is not supposed to have to think about heap or stack in go, from what I understand (I am by no means an expert).  The proposed solution sounds like it would create a cyclic dependency.

> Reuse heap allocations of handler results
> -----------------------------------------
>
>                 Key: THRIFT-3864
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3864
>             Project: Thrift
>          Issue Type: Wish
>          Components: Go - Compiler, Go - Library
>            Reporter: Javier Zunzunegui
>            Priority: Minor
>
> I have a service (Golang) with a handler that returns a large slice. A new one is allocated every time, resulting in large heap allocations per client call, while it could be reused through a sync.Pool and improve the overall performance through fewer GC calls.
> (.thrift example)
> struct Slice {
> 	1: required list<Element> element
> }
> service MyService {
> 	Slice GetSlice() throws (...)
> }
> I have experimented with modifying the auto-generated code and got this functionality through adding a 
> (.go) pool.Put(*Slice) // adding the newly generated return value to a pool)
> call in https://github.com/apache/thrift/blob/master/compiler/cpp/src/generate/t_go_generator.cc#L2798 but doing so creates a nasty dependency between the handler and the processor.
> Modifying the signature of the handler should also work 
> (.go) GetSlice(*Slice) (*Slice, error)
> but does breaks all compatibility with previous compilers...
> Has some solution to this problem been explored? 
> If nothing else some optional Release(retval) after oprot.Flush() in https://github.com/apache/thrift/blob/master/compiler/cpp/src/generate/t_go_generator.cc#L2798 would be very helpful



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)