[ 
https://issues.apache.org/jira/browse/FLINK-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365925#comment-15365925
 ] 

Gabor Horvath commented on FLINK-3673:
--------------------------------------

According to our discussion at DataArtisans, we do not want to break the 
serialization format right now. The null checks for primitive types and the 
subclass checks for final types are already eliminated from the generated code, 
but the tags are still written out. In the future, when it is desirable to 
change the format, it might give some performance advantage to not to write 
those tags out. This way spills to the disk might happen less frequently.

> Annotations for code generation
> -------------------------------
>
>                 Key: FLINK-3673
>                 URL: https://issues.apache.org/jira/browse/FLINK-3673
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Type Serialization System
>            Reporter: Gabor Horvath
>            Assignee: Gabor Horvath
>              Labels: gsoc2016
>
> Annotations should be utilized to generate more efficient serialization code.
> Planned improvements:
> * Using never null annotations on a field, the serialized representation can 
> omit the 1 byte null tags and the serializer code handling this tag.
> * Using never null annotiation on the POJO, we can omit the top level null 
> tag.
> * Making a POJO final we can omit the subclass tag.
> The very same annotations can be used to make the getLength method much 
> smarter.
> Code generation is a prerequisite, to avoid runtime checks which could make 
> the common codepath (without annotations) slower.
> I could also annotate some internal Flink types to make them more efficient.
> The main risk: it would break savepoints created with a Flink version that 
> did not have annotation. We could either introduce a compatibility mode, or 
> force  users to recreate those save points.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to