You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Ozerov (JIRA)" <ji...@apache.org> on 2015/10/07 13:41:27 UTC

[jira] [Commented] (IGNITE-1420) .Net: Optimize metadata write.

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

Vladimir Ozerov commented on IGNITE-1420:
-----------------------------------------

Implemented. Benchmark with "Address" entiry shows 10% throughput increase without metadata (saved on field ID calculation) and 100% increase with metadata (no field IDs, no metadata table lookups).

> .Net: Optimize metadata write.
> ------------------------------
>
>                 Key: IGNITE-1420
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1420
>             Project: Ignite
>          Issue Type: Task
>          Components: interop
>    Affects Versions: 1.1.4
>            Reporter: Vladimir Ozerov
>            Assignee: Vladimir Ozerov
>             Fix For: ignite-1.5
>
>
> Currently we perform int dictionary lookup on each field write to track metadata updates. This could be less than optimal because metadata updates are very rare.
> Several optimizations can be applied here:
> 1) For types where we use reflection we can collect all metadata information only once and write it when the first object of a type gets marshalled. Nothing more is needed.
> 2) For "marshal aware" types we never know whether new metadata is expected or not. We can introduce tree-like structure. When serialization start we are on the top of it. Then we go down as the fields are written. If we cannot find the node for the given field ID - we are on the new path. Then we create a copy of a tree and continue our path collecting updates. Finally, we flush them to Java and update global tree with latest changes.
> This can be highly optimized for the most common cases when there is one, at most two paths for the given sequence:
> - When there is only one known path, data can be stored as array. We simply go through it and compare current field ID with expected. So this is just int[].
> - When there are more paths in some places, we can have int[] + dispatch map. For 2-4 paths its is just a binary switch. For more paths we can fallback to normal dictionary.



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