[
https://issues.apache.org/jira/browse/THRIFT-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662062#action_12662062
]
Bryan Duxbury commented on THRIFT-248:
--------------------------------------
I just did some tests with the prior BinaryProtocolAccelerated implementation
and the standard Ruby BinaryProtocol being used by the new c-impl struct code.
It's a pretty ad hoc test, but the results were that BinaryProtocolAccelerated
is only 3.5% faster than the Ruby version, once the struct code is in c. That's
a pretty negligible difference.
I'll poke around and see if it's going to take a ton of time to fix it to work
like a regular protocol so we can get the last few percent, but if it's going
to be effort intensive, I'd say we should just alias it back to BinaryProtocol
so stuff doesn't break and worry about it later.
> 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.
