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

ASF GitHub Bot commented on THRIFT-3431:
----------------------------------------

GitHub user thomaslee opened a pull request:

    https://github.com/apache/thrift/pull/704

    THRIFT-3431 Avoid an unnecessary HashMap lookup

    The "schemes" lookup that occurs on every read/write can add up
    under high throughput with lots of small messages.
    
    More detail in https://issues.apache.org/jira/browse/THRIFT-3431

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/thomaslee/thrift tom_scheme_branch

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/thrift/pull/704.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 #704
    
----
commit c53d08118ae3abe33e991525fbb64644ba29ce56
Author: Tom Lee <git...@tomlee.co>
Date:   2015-11-19T10:06:25Z

    THRIFT-3431 Avoid an unnecessary HashMap lookup
    
    The "schemes" lookup that occurs on every read/write can add up
    under high throughput with lots of small messages.

----


> Avoid "schemes" HashMap lookups during struct reads/writes
> ----------------------------------------------------------
>
>                 Key: THRIFT-3431
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3431
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Java - Compiler
>    Affects Versions: 0.9.3
>            Reporter: Tom Lee
>            Priority: Minor
>
> Generated Java code for structs doesn't need to do a HashMap lookup on every 
> read/write operation.
> Was surprised to see this show up in profilers under certain high throughput, 
> write-heavy loads. Unclear if the cost was in the hashCode() implementation 
> of the key or in the map lookup itself, but given this map never changes, for 
> now it seems like it can be pretty safely replaced with a simple (and, in 
> most cases, predictable) branch.



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

Reply via email to