[
https://issues.apache.org/jira/browse/LUCENENET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shad Storhaug reopened LUCENENET-642:
-------------------------------------
> 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
> Priority: Minor
> Fix For: Lucene.Net 4.8.0
>
> Original Estimate: 10h
> Remaining Estimate: 10h
>
> 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)
