[
https://issues.apache.org/jira/browse/DRILL-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716539#comment-15716539
]
Laurent Goujon commented on DRILL-5094:
---------------------------------------
Thanks for the pointer, I was not familiar with JOP, but it looks to be an
hardware implementation of the JVM, and the cost associated with the bytecode
operations. But does it translate the same way when running in an actual JVM?
Usually, I try to rely on JMH benchmarks if I feel something is in the hot path
and might need some optimizations (although it's hard to get them right), but
you mentionned that this method is only called once per query, so maybe we
don't need to optimize that hard?
Also if we want to be fair, we should look at the whole method and not just one
specific instruction. In the case of the compare method, there are 2
{{invokeinterface}} calls (the {{Entry#getValue()}} method) and 2
{{invokemethod}} calls (the {{Long#longValue()}} calls from unboxing), plus a
bunch of stuff (like {{checkcast}} calls which are implemented in Java in
JOP?). All combined, the {{invokestatic}} call seems to represent less than 10%
of the microcycles
> Assure Comparator to be transitive
> ----------------------------------
>
> Key: DRILL-5094
> URL: https://issues.apache.org/jira/browse/DRILL-5094
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Chunhui Shi
> Assignee: Chunhui Shi
> Priority: Critical
> Labels: ready-to-commit
>
> In AssignmentCreator.java, one Comparator could break transitive attribute
> required for a Comparator implementation and the result is not correct.
> E.g. for:
> long IntPlusOne = 0x80000000L;
> [0]=2 * IntPlusOne + 5, [1] = 2* IntPlusOne + 8, [2] = 4 * IntPlusOne + 4,
> the compare results will be like:
> compare([0],[1]) = -3,
> compare([1],[2]) = 4,
> compare([0],[2]) = 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
