[
https://issues.apache.org/jira/browse/THRIFT-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15351684#comment-15351684
]
Jens Geyer commented on THRIFT-3864:
------------------------------------
Let me put it this way: From what I know the GC is Java is by no means the 100%
perfect solution either. So if one knows about an yet unfixed issue in the
underlying ecosystem, having at least a workaround at hand sounds not so bad to
me. Whether it is Java or Go or anything else.
So from my point of view iff we can have a
* working solution,
* that is more efficent in terms of throughput
* and does not introduce other problems
then (and only then) we should have a look at it.
Now the big question: Is this the case?
> 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)
