[
https://issues.apache.org/jira/browse/THRIFT-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733103#comment-16733103
]
Can Celasun commented on THRIFT-3864:
-------------------------------------
There is no clean way to implement this without a fairly ugly BC break. Go's
garbage collector has also improved dramatically since this issue was opened,
so I'm going to close this. If anyone still has concerns or ideas, please
reopen.
> 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)
