[
https://issues.apache.org/jira/browse/LUCENENET-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776848#action_12776848
]
Nicholas Paldino commented on LUCENENET-232:
--------------------------------------------
Michael,
I advise against this because it reeks of premature optimization. JIT
compilation will inline functions that it sees fit, and unless you have a
performance test that shows that this implementation is affecting performance
^that^ adversely, I would advise that you keep it in a method until it is
determined that it is a performance issue.
- Nick
> Inlining Unsigned Right Shift
> -----------------------------
>
> Key: LUCENENET-232
> URL: https://issues.apache.org/jira/browse/LUCENENET-232
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Michael Garski
> Priority: Minor
>
> As .NET does not have an unisgned right shift operator (>>>) as Java does,
> two overloads of SupportClass.Number.URShift exist to perform the operation
> for longs and ints. The original Java conversion spit out an incorrect
> implementation:
> The converted implementation is:
> {code}
> if (number >= 0)
> return number >> bits;
> else
> return (number >> bits) + (2 << ~bits);
> {code}
> The correct implementation is:
> {code}
> (long)(((ulong)number) >> bits);
> {code}
> I submitted a patch for LUCENENET-230 that corrects the implementation,
> however the shifting should be in-lined as opposed to broken out in a method
> to remain performant. This issue will cover the in-lining.
> I'm marking this as a minor improvement at this time as I have not measured
> the performance impact.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
