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

Ben Craig commented on THRIFT-2252:
-----------------------------------

On the C++ side, if we were to implement this, here's how I would do it...
Make a new class that inherits from TProtocol.  For the sake of discussion, 
let's call it TTinyProtocol.

This protocol would have a constructor argument or a setter method that would 
take some mapping from int to string.  The mapping object would be code 
generated.

When existing structs are read or written, they will still call 
read/writeMessageBegin(string, type, seqid).  The implementation of those 
methods would turn the string in the function prototype into the int that goes 
to the raw transport.

So this would require some code generator work, but it would just be additive.  
You wouldn't need massive changes.

> Optimize the overhead of the tag message of the request
> -------------------------------------------------------
>
>                 Key: THRIFT-2252
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2252
>             Project: Thrift
>          Issue Type: Improvement
>            Reporter: George Cao
>              Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of  a tag message(TMessage) 
> and the API arguments.
> This tag message includes the API name(method name), message type and a 
> sequence ID. 
> Compare to the API arguments which usually are some structure data like 
> integers, the tag message will cause a lot of overhead because of the API 
> name string.
> For example, assume we have an API like this in Java:
> {code}
> int getSomeEntityById(int id);
> {code}
> The the tag message will takes *len("getSomeEntityById") + 1 + 4 = 22* bytes 
> and the API arguments only takes 4 bytes.
>  
> Even worse if we support multiplexing, because we need append additional 
> service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?  
> Then we can avoid using the verbose string names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to