[jira] [Comment Edited] (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=14351557#comment-14351557 ] 

Jens Geyer edited comment on THRIFT-2941 at 3/7/15 12:51 PM:
-------------------------------------------------------------

Have you measured this? A {{map[]}} access is should be quite fast already.  How is the switch going to improve that?

According to [this thread|https://groups.google.com/forum/#!topic/golang-nuts/VUtUmxm2ubU], a hash table is used with O(1). Not sure about the switch, and not sure about hash vs. string comparison, but in the inheritance case one will end up with one switch per level, and at least that's probably no longer as quick as the hash lookup.

So having some actual (real worldly) numbers would be a great thing.




was (Author: jensg):
Have you measured this? A {{map[]}} access should be quite fast already. How is the switch going to improve that?

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