lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Paldino (JIRA)" <>
Subject [jira] Commented: (LUCENENET-232) Inlining Unsigned Right Shift
Date Thu, 12 Nov 2009 05:27:39 GMT


Nicholas Paldino commented on LUCENENET-232:


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:
>             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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message