[jira] [Commented] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
[ https://issues.apache.org/jira/browse/IGNITE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010584#comment-15010584 ] ASF GitHub Bot commented on IGNITE-1613: Github user ptupitsyn closed the pull request at: https://github.com/apache/ignite/pull/132 > 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: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 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)
[jira] [Commented] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
[ https://issues.apache.org/jira/browse/IGNITE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943390#comment-14943390 ] ASF GitHub Bot commented on IGNITE-1613: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/132 IGNITE-1613 Platform .Net: Investigate Guid/DateTime/String interoperability with Java You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1613 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/132.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #132 commit 703ba2a8746ab3a55616dc8a4ec56fa11f384ffe Author: ptupitsyn Date: 2015-10-05T09:54:06Z IGNITE-1613 Platform .Net: Investigate Guid/DateTime/String interoperability with Java commit 5237a464d4f4d424290818ea12db092feacd2d10 Author: ptupitsyn Date: 2015-10-05T11:02:08Z wip commit 7aaaef8392657ad9183e66d4293e9ee5de9d7724 Author: ptupitsyn Date: 2015-10-05T11:12:39Z Improve write benchmark commit 3bec1711aa62a913c36117f2d6cfabb58e1783d7 Author: ptupitsyn Date: 2015-10-05T11:14:31Z wip commit 19514cf73c2f54979edb257ccd0184749d642fe4 Author: ptupitsyn Date: 2015-10-05T12:16:14Z wip Guid commit 5f710b65b3c05ba66ef6be6f748d72185d71ba65 Author: ptupitsyn Date: 2015-10-05T12:46:22Z WriteGuid with structs commit 8b04b05e92fbc9e3eef67654e1103eb05dda18bd Author: ptupitsyn Date: 2015-10-05T12:50:14Z wip commit 815acaf56fd60bedb45bc7184d41b5e61f1ab5db Author: ptupitsyn Date: 2015-10-05T13:02:43Z wip commit 91d067905993d37abb0ef3750334e8cfe6308568 Author: ptupitsyn Date: 2015-10-05T13:23:19Z bitshifts commit 0e5560cb041b3906cb45c5b6315c33871b7bfd51 Author: ptupitsyn Date: 2015-10-05T13:28:17Z wip guids commit cd5756c4e26ad7e3f5abc05a2594ee6e6f45acdd Author: ptupitsyn Date: 2015-10-05T13:46:31Z Guid marshalling cleanup > 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)
[jira] [Commented] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
[ https://issues.apache.org/jira/browse/IGNITE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943388#comment-14943388 ] Pavel Tupitsyn commented on IGNITE-1613: - Guid: * Since we write all 16 bytes separately, bottleneck is mostly in EnsureWriteCapacityAndShift and such. * To write Guid in a single operation and avoid array allocations on heap, I've used structs with sequential layout. This way guid conversion has very little overhead. Newly added benchmark shows 25% improvement. > 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)
[jira] [Commented] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
[ https://issues.apache.org/jira/browse/IGNITE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943269#comment-14943269 ] Pavel Tupitsyn commented on IGNITE-1613: - DateTime: * Bottleneck is ToUniversalTime() call. We can't get rid of it or cache UTC ticks offset because it can lead to bugs with daylight savings and such. * Current marshalling format is (long milliseconds) + (int nanoSecondPart). Java uses it for both Date (which is expressed as a single long, in milliseconds) and Timestamp (which is in nanoseconds) * .Net DateTime is a single long, in ticks. 1 tick = 100 nanoseconds. So interop format carries more info than we need, and Write->Read roundtrip will always return the same value * We could separate Date and Timestamp serialization in Java to improve performance, but it would complicate .Net interop since (Java Date precision) < (.Net DateTime precision) < (Java Timestamp precision). > 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)
[jira] [Commented] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
[ 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)
