thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: thrift to Java mapping question: "list<byte>" mapping to"List<Byte>" (measured results)
Date Thu, 22 Dec 2011 15:43:17 GMT
What about using ByteBuffer on top of a binary blob?  Doesn't that meet
your requirements for a list-like array wrapper?

On Thu, Dec 22, 2011 at 1:39 AM, Chris Miller <>wrote:

> FWIW, I evaluated Thrift a few years ago to use in a financial application
> for shifting around large quantities of floating point numbers (many
> billions). The inability for Thrift to handle lists/arrays of primitives
> efficiently in Java was a showstopper in terms of performance so we ended
> up rolling our own solution. I revisit this list evey now and again to see
> where things stand but I'm sad to see that this issue still isn't being
> addressed.
> I don't see why it isn't possible to create a "list-like" array wrapper
> for the various primitive types instead of resort to using j.u.List with
> autoboxing. Yes this does make usability slightly more awkward but the
> performance gains are *huge* and, in our case at least the gains *far*
> outweigh the downside. A feature like this could be made optional, with
> standard List<Double> code being generated for those who'd prefer a cleaner
> API.
> If anyone does eventually pick this up, note that preallocating arrays to
> the correct size where possible (similar to how new ArrayList(100); works)
> also has a noticable impact on performance.
> Chris
>  Lists are meant to be lists for convenience. Performance would be
>> nice, but turning them into *Buffers would be a major usability hit. I
>> recommended using binary for your list<byte> because typically a list
>> of bytes is a byte array. The same advice is not relevant to the other
>> types.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message