You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Javier Zunzunegui (JIRA)" <ji...@apache.org> on 2016/06/27 14:23:52 UTC

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

Javier Zunzunegui created THRIFT-3864:
-----------------------------------------

             Summary: 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)