[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14271043#comment-14271043 ] Jake Farrell commented on THRIFT-1854: -- [~vlovich] we appreciate the work put into this and your efforts to help contribute back, the concerns are around how we can make this more generic so other libraries similar to trove can be used and we are not adding direct trove support or other similar library into the compiler which may or may not have non-compatible licenses > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270571#comment-14270571 ] Vitali Lovich commented on THRIFT-1854: --- That doesn't feel like a compelling argument. 1: the generated code doesn't somehow cause thrift to use LGPL code. 2: the licensing issue was not raised at all until it turned out there are technical reasons why other mechanisms are currently insufficient for this. It kind of feels like perhaps there's a gut reaction against this change so it really doesn't matter what kind of change I would/could to enable such a feature. > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14269456#comment-14269456 ] Jake Farrell commented on THRIFT-1854: -- The sorted container uses common java.util code where this relies on a third party dependency which is not compatible with ASF licensing > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268626#comment-14268626 ] Vitali Lovich commented on THRIFT-1854: --- I also don't see why this change is so controversial given how little discussion THRIFT-1630 generated which added the sorted_container. > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268624#comment-14268624 ] Vitali Lovich commented on THRIFT-1854: --- It wouldn't make sense to bundle trove into a release. Let the end-user make that decision. What would a generic implementation look like? I've heard this multiple times in this thread but there hasn't been any kind of proposal put forward on what such a workable solution would look like. I'm not a full-time thrift developer so I'm not going to have the best set of information to inform any kind of design. > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268335#comment-14268335 ] Jake Farrell commented on THRIFT-1854: -- I'm still not in favor of committing this as it stands and would like to see a more generic implementation that did not pin it to just trove support. Also trove is LGPL which we would not be able to include [1] in any releases [1]: http://www.apache.org/legal/resolved.html#category-x > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268270#comment-14268270 ] Jens Geyer commented on THRIFT-1854: How can this made available in a language-agnostic way? I mean, we support something around 20 languages now and striving for a consistent way throughout all of them seems important to me. Otherwise, soner or later will will end up with lots of different implementations. Without a doubt having a handy, flexible tool is very valuable. On the other hand, [Simplicity, Transparency, Consistency and Performance|https://thrift.apache.org/about] are valuable goods too. We should keep that in mind, IMHO. > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268130#comment-14268130 ] Vitali Lovich commented on THRIFT-1854: --- Do you have any thoughts on the design? There's two ways I can see this being done: 1: Modify the lexer & parser to support custom type generation. Add templating support & have each language generator define what the injection points are & what variables are available for substitution. 2: Embed lua into the compiler & let it load lua files for custom types that define how to generate that code. I like option #2 more as it seems like it would be simpler (no changes to the parsing/lexing) & more flexible. Thoughts? > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268098#comment-14268098 ] Roger Meier commented on THRIFT-1854: - Yes, annotations as a generic approach would be great. Handle options in a more generic approach is another need on the compiler, see THRIFT-2790 I guess we should commit this and I would appriciate if Vitali could help us making the annotation features more generic. -roger ;-r > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268026#comment-14268026 ] Vitali Lovich commented on THRIFT-1854: --- I agree completely with you. My point was that the current mechanism is insufficient: there is no way to implement Trove at the moment with the current annotation mechanism. Given that sorted_containers are in already & they actually *could* be implemented via annotations, do you have an objection to putting in trove until a more generic mechanism is implemented? In fact, the trove implementation could inform the requirements of a more generic solution: it'll point out what the injection points need to be. With respect to your float example, you mean in-memory storage is cut in half, right? Transfer size should be unaffected since thrift only supports transporting doubles. > 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[
https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267220#comment-14267220
]
Vitali Lovich commented on THRIFT-1854:
---
Hey [~codesf]. I don't believe the recommended approach works, at least for
trove.
The trove interface is different from Java since it's dealing with unboxed
types. Iteration (for serialization) is different from regular Java
collections since none of those collections implement (nor can they) Iterable,
so they can't use regular for-loops.
Additionally, getting the key/value from an iterator is different for Trove -
it's .key()/.value() instead of .getKey()/.getValue().
Moreover, the suggested TFloatList wouldn't compile since a double cannot be
assigned to a float.
Finally, annotations are great for customization of individual fields.
However, it does make sense to have command-line switches so that you can
specify a default implementation without needing to do custom overrides.
That being said, I think there does need to be a more generic mechanism to
support this kind of thing.
Something like:
type "java" TroveDoubleList {
api = "gnu.trove.list.TDoubleList";
internal = "gnu.trove.list.array.TDoubleArrayList";
loopStart = "for (int i_$(iterator) = 0; i < $(container).size(); ++i)";
accessor = "$(container).getQuick(i_$(iterator))";
}
Then you can add an annotation like:
(java.type = TroveDoubleList)
However, nothing like this exists, so this feels OK as a compile-time switch.
> 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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[
https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267090#comment-14267090
]
Randy Abernethy commented on THRIFT-1854:
-
Hey [~roger.meier],
A little late in the game perhaps, but my preference for all language specific
type substitution would be to use IDL annotations (as CPP does for base types)
not compiler switches (as Java does now) and not custom IDL (as CPP does now
for collections). My bias is based on the following:
- consistency: annotations provide a single clean way to add language generator
specific instructions (IDL being reserved for pure cross language abstractions)
- flexibility: using annotations in IDL you can use different implementations
selectively (a compiler switch applies to the entire compiled IDL)
- open endedness: annotation types accept any string, allowing new
implementation types to be added without adding new IDL annotation definitions
or compiler switches
Presently we have custom IDL (e.g. 1: map cpp_type "std::unordered_map" ), command line switches (e.g. -gen
java:sorted_containers) and annotations (e.g. 1: i32 (cpp.type = "long")
counter) which is a bit confusing.
I would much rather see Thrift move to using annotations universally for
implementation specification:
{code:title=Annotations|borderStyle=solid}
struct anno {
1: i32 (cpp.type = "long") counter
2: list (cpp.type = "std::vector", java.type =
"gnu.trove.list.TFloatList") values
3: list (cpp.type = "std::vector", java.type =
"gnu.trove.list.TFloatList") values
} (final="true")
{code}
The annotation parser already supports the above syntax.
Thoughts?
-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-adding-support-to-use-Trove-0.9-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-0.9.2-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-0.9.2-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-lists-for-lists.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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[
https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267021#comment-14267021
]
Roger Meier commented on THRIFT-1854:
-
I'm fine with this as long as it is only a compiler option.
The only thing I would change befor committing this is:
{noformat}
-"trove_lists: Use Trove array lists where possible instead of Java
native collections.\n"
+"trove_lists: Use GNU Trove(net.sf.trove4j) array lists where possible
instead of Java native collections.\n"
{noformat}
any concerncs?
> 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-0.9.2-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-lists-for-lists.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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14265658#comment-14265658 ] Vitali Lovich commented on THRIFT-1854: --- Ping. > 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch, > 0001-adding-support-to-use-Trove-lists-for-lists.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)
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642991#comment-13642991 ] Vitali Lovich commented on THRIFT-1854: --- Is there an alternate suggestion if adding trove as an optional dependency is not an option? > 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch, > 0001-adding-support-to-use-Trove-lists-for-lists.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611132#comment-13611132 ] Vitali Lovich commented on THRIFT-1854: --- It's optional & Java doesn't have any built-in collections specialized for primitives. Guava plays a different role IMHO. Guava is largely stylistic enhancements whereas Trove provides different functionality (faster code, less memory overhead). Apache commons is already used when hash code is enabled; this is along the same lines (trove is only a dependency if you enable it explicitly) but provides even more utility than the HashCodeBuilder dependency. > 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch, > 0001-adding-support-to-use-Trove-lists-for-lists.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611040#comment-13611040 ] Jake Farrell commented on THRIFT-1854: -- We have tried to keep the core java library as lean and dependency free as possible to allow for the library to be able to be plugged into any application easily. Guava was considered and not used due to this reason > 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch, > 0001-adding-support-to-use-Trove-lists-for-lists.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1854) trove support for lists of primitives
[ https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611030#comment-13611030 ] Roger Meier commented on THRIFT-1854: - Is there an alternative to gnu.trove.list? I'm a big fan of minimal dependencies... > 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch, > 0001-adding-support-to-use-Trove-lists-for-lists.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
