[
https://issues.apache.org/jira/browse/AVRO-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16657219#comment-16657219
]
ASF GitHub Bot commented on AVRO-2090:
--------------------------------------
rstata commented on a change in pull request #350: AVRO-2090 second try
URL: https://github.com/apache/avro/pull/350#discussion_r226733860
##########
File path:
lang/java/avro/src/main/java/org/apache/avro/specific/SpecificData.java
##########
@@ -122,6 +122,11 @@ public DatumWriter createDatumWriter(Schema schema) {
/** Return the singleton instance. */
public static SpecificData get() { return INSTANCE; }
+ private boolean useCustomCoderFlag
+ =
Boolean.parseBoolean(System.getProperty("org.apache.avro.specific.use_custom_coders","false"));
+ public boolean useCustomCoders() { return useCustomCoderFlag; }
+ public void setCustomCoders(boolean flag) { useCustomCoderFlag = flag; }
+
Review comment:
Regarding compiler options: the controlability here isn't intended to be a
long-term option, it's intended to be a "feature flag" that allows more
risk-seeking users to use the feature early and help find corner-case bugs.
After a release or two, the flag should go away and this should be the only way
to generate code. As a result, this feature flag is more appropriate as a
runtime option (as it is now), vs. a compile-time option. For example, imagine
the scenario where the custom coders look really good during testing, they get
shipped to production, and a bug is tickled. In this scenario, the ops team
will want to turn off the custom coders with a runtime flag, rather than wait
for the system to be recompiled with a change to the compile-time flag.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Improve encode/decode time for SpecificRecord using code generation
> -------------------------------------------------------------------
>
> Key: AVRO-2090
> URL: https://issues.apache.org/jira/browse/AVRO-2090
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Raymie Stata
> Assignee: Raymie Stata
> Priority: Major
> Attachments: customcoders.md, perf-data.txt
>
>
> Compared to GenericRecords, SpecificRecords offer type-safety plus the
> performance of traditional getters/setters/instance variables. But these are
> only beneficial to Java code accessing those records. SpecificRecords
> inherit serialization and deserialization code from GenericRecords, which is
> dynamic and thus slow (in fact, benchmarks show that serialization and
> deserialization is _slower_ for SpecificRecord than for GenericRecord).
> This patch extends record.vm to generate custom, higher-performance encoder
> and decoder functions for SpecificRecords. We've run a public benchmark
> showing that the new code reduces serialization time by 2/3 and
> deserialization time by close to 50%.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
