[ https://issues.apache.org/jira/browse/THRIFT-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Can Celasun closed THRIFT-3864. ------------------------------- Resolution: Won't Do > 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 (v7.6.3#76005)