[
https://issues.apache.org/jira/browse/THRIFT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666066#action_12666066
]
Bryan Duxbury commented on THRIFT-110:
--------------------------------------
{quote}
+ lastField_.push(new TField(field));
Avoid allocation by re-using the previous TField. You might want to make it an
ArrayList<TField> and use an int to keep track of the position of the stack.
That way, you don't have to re-allocate when you enter/exit a struct.
{quote}
Well, at first I just used the TField directly. However, the generated struct
serialization code reuses the TField objects, so if I don't copy them, nothing
works.
Forgot to remove writeVarint16 method. It's unused at the moment.
{quote}
+ lastField_.push(field);
+ return field;
TField is not immutable, so you shouldn't do this.
{quote}
Hm, true, but the alternative is copying the object before returning it, and
it's unlikely the caller is going to modify it. We should probably just make
the fields on TField final.
{quote}
+ byte[] buf = new byte[1];
+ trans_.read(buf, 0, 1);
Allocate per class
{quote}
I assume you mean that I should just keep a protocol-level single-byte buffer
for this purpose.
{quote}
+ switch ((byte)(type & 0x0f)) {
Use an array + lookup up (it's a shame that Java can't have a const array that
is mapped into memory)
{quote}
Sounds like a good idea, but I'd like to have a benchmark built first before
making optimizations.
Thanks for the thoughtful comments.
> A more compact format
> ----------------------
>
> Key: THRIFT-110
> URL: https://issues.apache.org/jira/browse/THRIFT-110
> Project: Thrift
> Issue Type: Improvement
> Reporter: Noble Paul
> Attachments: compact-proto-spec-2.txt, compact_proto_spec.txt,
> compact_proto_spec.txt, thrift-110-v2.patch, thrift-110-v3.patch,
> thrift-110-v4.patch, thrift-110-v5.patch, thrift-110-v6.patch,
> thrift-110.patch
>
>
> Thrift is not very compact in writing out data as (say protobuf) . It does
> not have the concept of variable length integers and various other
> optimizations possible . In Solr we use a lot of such optimizations to make a
> very compact payload. Thrift has a lot common with that format.
> It is all done in a single class
> http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/common/util/NamedListCodec.java?revision=685640&view=markup
> The other optimizations include writing type/value in same byte, very fast
> writes of Strings, externalizable strings etc
> We could use a thrift format for non-java clients and I would like to see it
> as compact as the current java version
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
