You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Peter (Jira)" <ji...@apache.org> on 2021/02/17 08:29:00 UTC

[jira] [Updated] (AVRO-3048) Using builders leads to performance degradation

     [ https://issues.apache.org/jira/browse/AVRO-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter updated AVRO-3048:
------------------------
    Description: 
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)

  was:
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)


> 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
>            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)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)