lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (Jira)" <j...@apache.org>
Subject [jira] [Created] (LUCENENET-642) Eliminate Runtime Reflection Code from TokenStream
Date Mon, 03 Feb 2020 05:43:00 GMT
Shad Storhaug created LUCENENET-642:
---------------------------------------

             Summary: Eliminate Runtime Reflection Code from TokenStream
                 Key: LUCENENET-642
                 URL: https://issues.apache.org/jira/browse/LUCENENET-642
             Project: Lucene.Net
          Issue Type: Task
          Components: Lucene.Net Core
    Affects Versions: Lucene.Net 4.8.0
            Reporter: Shad Storhaug
            Assignee: Shad Storhaug


As per LUCENENET-640, the {{TokenStream.AssertFinal}} method is causing performance issues.
This method was used to assert that the usage of {{TokenStream}} is correct - that is, subclasses
or their {{IncrementToken()}} method must be sealed.

In Java, there is not a performance issue because asserts are presumably turned off in production
applications and the Reflection overhead only happens when debugging. However, in .NET asserts
are compiled out of the final release so doing it in a similar way would disable the feature
for end users.

Instead, we should create Rosnlyn code analyzers to ensure the project doesn't compile unless
the end user seals either the class or its {{IncrementToken()}} method. This effectively means
we leave the heavy code analysis up to the IDE/build and it doesn't run at all in production.

Per [this article|https://docs.microsoft.com/en-us/archive/msdn-magazine/2015/october/code-analysis-build-and-deploy-libraries-with-integrated-roslyn-code-analysis-to-nuget],
it is feasible to package a code analyzer into the {{Lucene.Net}} NuGet package so when it
is installed the code analysis will take effect in the IDE.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message