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

Bryan Duxbury commented on THRIFT-248:
--------------------------------------

I take it back. I messed something up with my prior benchmark. Here are some 
updated numbers:

 * Trunk, Ruby binary protocol
 ** Write: 5.17s
 ** Read: 3.92s
 * Trunk, BinaryProtocolAccelerated
 ** Write: 0.59s
 ** Read: 0.48s
 * thrift_native
 ** Write: 1.88s
 ** Read: 2.82s

It looks like there may yet be some performance gains to be had in the 
protocol. I'll experiment more and see what I come up with.

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

Reply via email to