[
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
(v6.3.4#6332)
