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

ASF GitHub Bot commented on FLINK-8172:
---------------------------------------

Github user NicoK commented on a diff in the pull request:

    https://github.com/apache/flink/pull/5104#discussion_r154024973
  
    --- Diff: 
flink-runtime/src/main/java/org/apache/flink/runtime/io/network/api/serialization/SpanningRecordSerializer.java
 ---
    @@ -107,6 +110,7 @@ public SerializationResult addRecord(T record) throws 
IOException {
        @Override
        public SerializationResult setNextBuffer(Buffer buffer) throws 
IOException {
    --- End diff --
    
    Actually, whether we are the sole owner of the `buffer` now depends on the 
outside and this adds a pretty heavy implicit assumption. Why not make the 
`SpanningRecordSerializer` work with the `BufferProvider` of the 
`targetPartition` directly, e.g. either by adding it at construction time or as 
a parameter. We'd then probably have to rename the `setNextBuffer` method but 
can keep the logic and make sure we are the sole owner.


> Remove unnecessary synchronisation in RecordSerializer
> ------------------------------------------------------
>
>                 Key: FLINK-8172
>                 URL: https://issues.apache.org/jira/browse/FLINK-8172
>             Project: Flink
>          Issue Type: Improvement
>          Components: Network
>    Affects Versions: 1.4.0, 1.3.2
>            Reporter: Piotr Nowojski
>            Assignee: Piotr Nowojski
>             Fix For: 1.5.0
>
>
> While writing the records, RecordSerializer is the only owner of the `Buffer` 
> into which data are written. Yet we are synchronisation twice per record 
> while accessing MemorySegment. Removing this synchronisation speeds up the 
> Network throughput in point to point benchmark by a factor of two (from 
> ~12500records/ms up to 23000 records/ms).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to