[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397690#comment-13397690
]
Christopher Currens commented on LUCENENET-480:
-----------------------------------------------
Regarding the sorted SortedSet implementation, I might consider using a
{{SortedDictionary<T>}} internally instead of a {{SortedList<T>}}. It's faster
at removals and insertions, at the cost of a little more memory. I think in
the cases where SortedSet is used in Lucene, it won't make much of a difference
at all in memory usage, but could use the speed.
> Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
> ------------------------------------------------------------------------------
>
> Key: LUCENENET-480
> URL: https://issues.apache.org/jira/browse/LUCENENET-480
> Project: Lucene.Net
> Issue Type: Task
> Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
> Lucene.Net Test
> Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
> Reporter: Christopher Currens
> Attachments: SortedSet.cs
>
>
> We need to investigate what needs to be done with the source to be able to
> support both a .NET 3.5 and 4.0 build. There was some concern from at least
> one member of the community ([see
> here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E])
> that we've alienated some of our user base by making such a heavy jump from
> 2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based
> runtimes, specifically FAR superior memory management, particularly with the
> LOH, where Lucene.NET has had major trouble with in the past.
> Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop
> .NET 3.5/3.0 libraries and go back to 2.0. HashSet<T> and ISet<T> is used
> extensively in the code, that would be a major blocker to get done. I
> suppose it could be possible, but there hasn't been a whole lot of talk about
> what runtimes we intend to support. The big change between lucene 2.x and
> 3.x for java was also a change in runtimes, that allowed generics and enums
> to be used in the base code. We have a similar situation with the API (it's
> substantially different, with the addition of properties alone) for this next
> version of Lucene.NET, so I think it's reasonable to at least make a
> permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been
> discussed with the committers.
> It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent
> compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we
> should try our best to support it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
