[
https://issues.apache.org/jira/browse/THRIFT-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14274411#comment-14274411
]
ASF GitHub Bot commented on THRIFT-2941:
----------------------------------------
GitHub user captncraig opened a pull request:
https://github.com/apache/thrift/pull/356
THRIFT-2941
https://issues.apache.org/jira/browse/THRIFT-2941
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/captncraig/thrift THRIFT-2941
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/356.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #356
----
commit f4e5f0c29e14a689ec00931ffc44d416c95858d4
Author: Craig Peterson <[email protected]>
Date: 2015-01-12T23:37:42Z
converting processor to use switch instead of map
----
> 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
>
> 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)