[
https://issues.apache.org/jira/browse/AVRO-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978151#action_12978151
]
Scott Carey commented on AVRO-726:
----------------------------------
We should definitely consider this so that such extensions are possible.
As for the use case above, the latest version of Avro uses Velocity templates
for SpecificRecord generation -- so you could generate classes with all the
getter/setters you want. One of the items I wanted to get to was to experiment
with ways to remove the boxing/unboxing overhead for these objects.
IndexedRecord neatly simplifies access to fields but has the boxing overhead.
Are you willing to share or contribute what you have done so far?
There are some approaches I have considered. I was going to take a stab at
'merging' the Reflect and Specific API by way of annotations to get rid of this
overhead -- essentially have the code gen create annotated classes that
specified how the schema maps to the fields -- and have reflect consume those.
Later down the road, Reflect could use cgilib and/or asm to create
serialization / deserialization classes on the fly that would be compiled to
very very efficient code and be faster than the current Specific API.
Lastly, note that autoboxing/unboxing in some cases has become 'free' on the
latest Sun JVM with '-XX:+UseEscapeAnalysis' on. This will default to on in a
later JVM release. If the object is boxed manually (using new Integer(), not
Integer.valueOf()) and the object does not escape a small enough code block,
the JVM will avoid object creation entirely. This can help some of the
IndexedRecord API usage.
> Make GenericDatumReader/GenericDatumWriter data member protected so that it
> can be used by the derived classes
> --------------------------------------------------------------------------------------------------------------
>
> Key: AVRO-726
> URL: https://issues.apache.org/jira/browse/AVRO-726
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.5.0
> Reporter: Xiaolu Ye
> Fix For: 1.5.0
>
>
> Currently, GenericDatumReader/GenericDatumWriter data members are private. Is
> it possible to make them protected so that we could extend those classes and
> create our own special DatumReader/Writer? The reason we want to do that is
> because we've created our own base SpecificRecordEx that implements
> SpecificRecord and added put/get for primitive types. We now want to extend
> the GenericDatumReader/GenericDatumWriter to use those primitive put/get
> functions to reduce box/unbox for better performance.
> Thanks,
> Xiaolu
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
