[
https://issues.apache.org/jira/browse/AVRO-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338467#comment-17338467
]
Martin Jubelgas commented on AVRO-3048:
---------------------------------------
Yes, I agree that the class loader overhead can be avoided by cloning existing
builders where performance is an issue. I had been thinking of the same thing,
but am still pondering possible paths to enhance the performance of existing
user code without degrading performance in other cases.
About your last question, you're right. In fact, the current PR does not reduce
any calls {{newInstance(...)}} at all, and I agree in cases with expensive
class loaders, this might cause similar performance impact.
One possible solutions where {{newInstance()}} functionality is required and
classloader calls are too expensive might be to use the methods I added to
{{GenericData}} and {{SpecificData}} to speed up instantiation in the
fast-reader implementation:
{code:java}
// cache all the nasty reflection lookups in the instance supplier used in the
fast-reader
InstanceSupplier supplier = specificData.getNewRecordSupplier(schema);
// generate the new record whenever one instance is required
Object specificRecord = supplier.newInstance(null,schema);
{code}
For starters, it might suffice to give this functionality some love as in
adding some more reference and explanation to it in the documentation.
Given that's the way we wanna proceed with it, I am sure I can put in some work
on prettying up some things around there, but I am open to other suggestions to
deal with things.
> 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)
