[jira] [Commented] (THRIFT-2941) Convert processor to use switch instead of map

["Jens Geyer (JIRA)" <ji...@apache.org>]

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

Jens Geyer commented on THRIFT-2941:
------------------------------------

Hi [~captncraig], 

sorry I somehow overlooked that patch. I tried to merge it and everything looks fine so far, except that I get this with the tutorial code after applying the patch:

{code}
tutorial\calculator.go:346: p.shared undefined (type *CalculatorProcessor has no field or method shared)
tutorial\calculator.go:346: not enough arguments to return
tutorial\calculator.go:351: undefined: Newshared
{code}


> Convert processor to use switch instead of map
> ----------------------------------------------
>
>                 Key: THRIFT-2941
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2941
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Go - Compiler
>            Reporter: Craig Peterson
>            Assignee: Jens Geyer
>
> We are using a special protocol extension to insert auxiliary tracking data into our method names on certain services. Our implementation works by creating a special Processor Wrapper and creating a new Handler/Processor for each request. 
> The current implementation of the generated handler makes this rather expensive, as a new map is created each time you create a processor. I propose reworking the generated processor to use a switch structure for dispatch rather than the current map-based solution.
> A summary of the differences before and after for a small example can be found in this gist: https://gist.github.com/captncraig/e2bc7e7d1a0cb2c8127b#file-foo-thrift
> I ran benchmarks and the baseline performance (both in time and allocations) of the processor seem almost exactly the same after my changes. My modified/wrapped processor however is able to perform much faster and with less memory with these changes. 
> No application code should need to be changed unless it was interacting with the exported processor map functions (which I suspect should have been private all along).
> Working on a patch right now.



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