[
https://issues.apache.org/jira/browse/AVRO-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338975#comment-17338975
]
Ryan Skraba commented on AVRO-3048:
-----------------------------------
On the positive side, your PR fixes exactly the problem described in this Jira
for the unnecessary {{*Class.forName*}} call! Lets merge it and consider this
Jira fixed for building new records. I checked this by running the newBuilder
If you want to write an improvement for the read path to avoid reflection,
let's do it in another Jira. It's also probably worthwhile discussing when we
finally turn on the fast-reader implementation as the default!
> Using builders leads to performance degradation
> -----------------------------------------------
>
> Key: AVRO-3048
> URL: https://issues.apache.org/jira/browse/AVRO-3048
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.9.2, 1.10.1
> Reporter: Peter
> Assignee: Martin Jubelgas
> Priority: Major
>
> When you do a .newBuilder() for avro generated classes, this will call
> org.apache.avro.specific.SpecificData.getForSchema:
>
> public static SpecificData getForSchema(Schema reader) {
> if (reader.getType() == Type.RECORD) {
> final String className = getClassName(reader);
> if (className != null) {
> final Class<?> clazz;
> try
> {
> clazz = Class.forName(className);
> return getForClass(clazz); }
> catch (ClassNotFoundException e)
> { return SpecificData.get();
> }
> }
> }
>
> which seems then to seldom find the value inside the try and a lot of
> ClassNotFoundException is thrown.
> Throwing internal exceptions has great performance penalties and in practice
> users of avro 1.9.x. and 1.10.x in high performance applications are forced
> not to use builders.
>
> Information about same problem is also found on:
> [https://forums.databricks.com/questions/50803/orgapacheavrospecificspecificdatagetforschema-sear.html]
> Problem exists on at least 1.9.2 and 1.10.1 (but not on 1.7.x) in OSGI
> environment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
