[jira] Resolved: (THRIFT-248) Factor BinaryProtocolAccelerated into separate protocol and struct components

["Bryan Duxbury (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Duxbury resolved THRIFT-248.
----------------------------------

    Resolution: Fixed

I just committed this. Thanks for all the hand-holding, Kevin!

> Factor BinaryProtocolAccelerated into separate protocol and struct components
> -----------------------------------------------------------------------------
>
>                 Key: THRIFT-248
>                 URL: https://issues.apache.org/jira/browse/THRIFT-248
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Library (Ruby)
>            Reporter: Bryan Duxbury
>            Assignee: Bryan Duxbury
>            Priority: Minor
>         Attachments: thrift-248-v2.patch, thrift-248-v3.patch, thrift-248-v4.patch, thrift-248-v5.patch, thrift-248-v6.patch, thrift-248-v7.patch, thrift-248.patch
>
>
> Kevin Clark's excelled BinaryProtocolAccelerated implementation in the Ruby library is very fast, in large part due to the fact that it implements not just the protocol but also the struct components of serialization directly as a C extension. The problem with this arrangement is that other protocols that would benefit from accelerated struct code don't get the benefit. In particular, I'd like to make my implementation of the Compact Protocol fast in Ruby, and the key appears to be the struct serialization code. 
> I think that we should make an effort to divorce the struct stuff from the protocol stuff in BinaryProtocolAccelerated, so that all protocols can benefit. Some quick benchmarking seems to indicate that there is going to be some additional method call overhead in this situation, but it's not really that substantial. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.