thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Miller <>
Subject Re: thrift to Java mapping question: "list<byte>" mapping to"List<Byte>" (measured results)
Date Thu, 22 Dec 2011 09:39:54 GMT
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.


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

View raw message