Re: thrift to Java mapping question: "list" mapping to"List" (measured results)

[Chris Miller <ch...@hotmail.com>]

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.

Re: thrift to Java mapping question: "list" mappingto"List" (measured results)

[Chris Miller <ch...@hotmail.com>]

> What about using ByteBuffer on top of a binary blob?  Doesn't that
> meet your requirements for a list-like array wrapper?

I'm sure that's possible but as I understand it this would mean specifying 
a type of binary rather than eg list<double>. Additional complexity in the 
Java code aside, this would also infect the code of other languages we're 
interfacing with.

>From my point of view at least, finding a workaround with Thrift is a bit 
of a moot point anyway since we already have a solution in place. I really 
just wanted to chip in and point out the problem is real, and for some cases 
a very significant one.

Looking at the bigger picture, I've been hoping for a long time now that 
there would be some progress in supporting XOPs in the VM (see http://blogs.oracle.com/jrose/entry/fixnums_in_the_vm 
for a discussion). This would greatly reduce the overhead of many boxed primitive 
operations, and would mean libraries like Thrift wouldn't generally need 
to consider trading off usability with performance.

Re: thrift to Java mapping question: "list" mapping to"List" (measured results)

[Ted Dunning <te...@gmail.com>]

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 <ch...@hotmail.com>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.
>>
>
>
>
>