[
https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267303#comment-14267303
]
Randy Abernethy commented on THRIFT-1854:
-----------------------------------------
Hey [~vlovich],
I agree that the language generator needs to create specialized code for type
substitution (the float example is simply an example folks use to cut transfer
sizes for doubles in half). I am not suggesting that you change your
implementation, or that new types should be swapped in lexically. I think your
implementation looks great as it is.
My concern is only related to the compiler switch as the trigger for the
implementation. If every language needs a switch for each new type substitution
we are going to have switch sprawl and switch conflicts. What if I want to use
Trove in one place and something else in another? What about specialized
collections for Python and Ruby? What happens when I use "-gen
java:sorted_containers" and the trove switch? It is going to get messy.
Annotations are self documenting, informative to the user and get checked in
with your IDL, providing a convenient versioned record of optimizations made.
At every use the compiler can easily and generically throw an error if there is
more than one type annotation for a particular language (a grammar issue not a
generator issue).
Using the annotation: (_lang_.type = "some new type") defines one pattern which
works for all languages, and, of particular importance, it is already in use.
You do certainly trade the globalness of a command line switch when you go with
annotations but, on balance, I think this is almost always upside in practice.
-Randy
> trove support for lists of primitives
> -------------------------------------
>
> Key: THRIFT-1854
> URL: https://issues.apache.org/jira/browse/THRIFT-1854
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Compiler
> Reporter: Vitali Lovich
> Attachments:
> 0001-Add-support-for-trove-option-to-Java-generator.patch,
> 0002-adding-support-to-use-Trove-lists-instead-of-native-.patch,
> 0003-Implement-trove-support-for-sets.patch,
> 0004-Implement-trove-support-for-maps.patch
>
>
> When dealing with large collections of primitive types, there can be
> significant memory (i.e. using arrays of objects instead of arrays of
> primitives) & runtime overhead (autoboxing/unboxing) using the default
> collections. Utilizing trove can significantly improve things. ideally
> support would be added for sets & maps, but as a first pass lists would be
> great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
