ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Tupitsyn (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
Date Mon, 05 Oct 2015 10:44:26 GMT

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

Pavel  Tupitsyn commented on IGNITE-1613:

String hashcodes performance investigation: 
* PortableUtils.StringHashCode takes ~8% of IPortableWriter.WriteString
* Caching results with ConcurrentDictionary or ThreadLocal Dictionary does not improve performance
(for short field names at least). And it is not surprising, because dictionary lookup includes
calculating string hash code with an internal algorithm, which is similar.
* Other caching possibilities are Tries (https://en.wikipedia.org/wiki/Trie) and precompiled
switches (http://blogs.msdn.com/b/jomo_fisher/archive/2007/03/28/fast-switching-with-linq.aspx).
These approaches are quite complicated, so I did not try them.

> Platform .Net: Investigate Guid/DateTime/String interoperability with Java
> --------------------------------------------------------------------------
>                 Key: IGNITE-1613
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1613
>             Project: Ignite
>          Issue Type: Task
>          Components: interop
>    Affects Versions: ignite-1.5
>            Reporter: Pavel  Tupitsyn
>            Assignee: Pavel  Tupitsyn
>             Fix For: ignite-1.5
> Currently in .Net we:
> * write Guid and DateTime in Java format
> * calculate string hash code for field names with Java algorithm on each call
> Need to investigate if the following makes sense:
> 1) In .Net always write Guid and DateTime in native .Net format as fast as possible;
Make Java understand that format. (Not every Guid written in .Net will be read in Java, so
we can win time).
> 2) Cache string hashcodes somehow.

This message was sent by Atlassian JIRA

View raw message