[
https://issues.apache.org/jira/browse/LUCENENET-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964369#comment-16964369
]
Shad Storhaug commented on LUCENENET-602:
-----------------------------------------
Stefano,
Thanks for the report. We used to use {{LruCache}} (or some similar class) and
it was compatible with the facet functionality, but we got some complaints
about performance. {{LurchTable}} was found to perform much better (on Windows,
anyway), primarily due to the locking contention that is present in
{{LruCache}}. Therefore, using {{LruCache}} as-is for any platforms that fully
support {{LurchTable}} is not an acceptable trade-off due to the performance
penalty.
Note that although no users have reported problems with it, this issue affects
some parts of Lucene.Net.QueryParser in addition to Lucene.Net.Facet.
I agree fixing the LRU cache is something that needs to be done but so far
there hasn't been enough information provided for us to fix it without taking a
performance hit. Of course, it would definitely help if our tests were setup to
run on Xamarin.iOS so we have a way to confirm that any change has a positive
effect, which is something that is currently up-for-grabs (see
[LUCENENET-633|https://issues.apache.org/jira/browse/LUCENENET-633]). Adding
testing support should be simpler to do now that we are setup on Azure DevOps
via YAML configuration.
If we cannot somehow patch {{LurchTable}} to make it work with Xamarin.iOS, the
next best option would be to detect when we are running on Xamarin.iOS and swap
the implementation to {{LruCache}} during initialization for only that case. I
found some information [on this StackOverflow
answer|https://stackoverflow.com/a/48260863] (which coincidentally is one that
I also answered) that seems like it might be a way to detect that specific
case, especially if you click through to the related documents. So, it seems
there is a way to detect {{Xamarin}} and a way to detect {{Device.iOS}}, and
hopefully combining the two methods should give us the specific behavior we
need to provide this swap only in the case where it is needed.
It would be extremely helpful if you could verify that the combination of the
above methods will indeed detect only Xamarin.iOS and not trigger on Xamarin in
general or iOS in general. It would be even more helpful if you could setup our
tests to run on Xamarin.iOS and provide tests we can run that confirm the
platform detection will work. Do note that the general place where we do
platform detection is in
[Lucene.Net.Util.Constants.cs|https://github.com/apache/lucenenet/blob/5c434545b31e8131485e00657b37685610358677/src/Lucene.Net/Util/Constants.cs].
The current thinking is to clean up all of our collections (including those
that we have absorbed from 3rd parties) and make them into 1st class features
that can be used by end users (see
[LUCENENET-616|https://issues.apache.org/jira/browse/LUCENENET-616]). However,
it goes beyond that - we have also absorbed a handful of Java-like types that
really need to be polished and put into a separate, stable general library that
can be utilized by Lucene.NET's dependencies to share interfaces, collections,
and other compatibility functionality that hasn't yet debuted in the .NET
ecosystem. We are sometimes running into issues where we cannot pass a type in
library A to library B because there is no common interface in the BCL to pass
it like there is in Java.
While it would certainly be better to submit PRs and get the collection
libraries up to speed as far as behavior, interfaces, and platform
compatibility is concerned, I am becoming convinced that it is not likely going
to happen. I [reported back in 2016 to the maintainers of C5 that their sets
don't support {{ISet<T>}}|https://github.com/sestoft/C5/issues/53] and although
they thought it might be a good idea to do, it still hasn't been done. I
recently started working on a PR, but found that C5 would require breaking API
changes to their dictionaries (or alternatively a compatibility wrapper) just
to make them compatible with common collection interfaces in the BCL.
Furthermore, they are already dropping support for .NET Framework 4.5 and .NET
Standard 1.x. So, we are likely going to have to build our own library of
collections in order to get the level of compatibility, stability, and most
importantly end-user usability we will need.
Anyway, any assistance that is provided to help us get to the bottom of this
without it costing us dearly in terms of performance would be appreciated.
> Error using Lucene.Net.Facet 4.8.0-beta00005 with Xamarin.iOS
> --------------------------------------------------------------
>
> Key: LUCENENET-602
> URL: https://issues.apache.org/jira/browse/LUCENENET-602
> Project: Lucene.Net
> Issue Type: Bug
> Components: Lucene.Net.Facet
> Affects Versions: Lucene.Net 4.8.0
> Environment: Xamarin Forms 3.0.0.561731
> Ios 10.3.3 and Higher
> Lucene.Net.Facet 4.8.0-beta00005
> Reporter: Enrico Caltran
> Priority: Minor
> Labels: AOT, Xamarin.iOS, lucene.net.facet
> Fix For: Lucene.Net 4.8.0
>
> Attachments: AppTestLucene.zip, image-2019-08-08-02-26-40-582.png
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> I'm using Lucene.Net.Facet 4.8.0-beta00005 in a big Xamarin project.
> +With Xamarin.Android and Xamarin.UWP it's all right.+
> *+But With Xamarin.iOS on device (Ipad)+*, i'm receiving this error:
> _Attempting to JIT compile method
> 'Lucene.Net.Support.LurchTable2<Lucene.Net.Facet.Taxonomy.FacetLabel,
> Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader/Int32Class>:InternalInsert<Lucene.Net.Support.LurchTable2/Add2Info<Lucene.Net.Facet.Taxonomy.FacetLabel,
> Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader/Int32Class>>
> (int,Lucene.Net.Facet.Taxonomy.FacetLabel,int&,Lucene.Net.Support.LurchTable`2/Add2Info<Lucene.Net.Facet.Taxonomy.FacetLabel,
> Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader/Int32Class>&)'
> while running in aot-only mode. See
> [https://developer.xamarin.com/guides/ios/advanced_topics/limitations/] for
> more information._
> _{color:#d04437}at Lucene.Net.Support.LurchTable2[TKey,TValue].Insert[T]
> (TKey key, T& value) <0x2570f48 + 0x000e0> in
> <063e095c95d945a4ace32ab83d1227eb#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
> at (wrapper unknown) System.Object.gsharedvt_in() at
> Lucene.Net.Support.LurchTable2[TKey,TValue].AddOrUpdate (TKey key, TValue
> addValue, Lucene.Net.Support.KeyValueUpdate2[TKey,TValue] fnUpdate)
> <0x232824c + 0x0013b> in
> <063e095c95d945a4ace32ab83d1227eb#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
> at Lucene.Net.Facet.Taxonomy.LRUHashMap2[TKey,TValue].Put (TKey key, TValue
> value) <0x2c487f8 + 0x0015b> in
> <79d3a7b905954d0993025c09c5d087ce#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0 at
> Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader.GetOrdinal
> (Lucene.Net.Facet.Taxonomy.FacetLabel cp) <0x2c51970 + 0x0019b> in
> <79d3a7b905954d0993025c09c5d087ce#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0 at
> Lucene.Net.Facet.Taxonomy.Int32TaxonomyFacets.GetTopChildren{color}
> (System.Int32 topN, System.String dim, System.String[] path) <0x2c481dc +
> 0x0008f> in
> <79d3a7b905954d0993025c09c5d087ce#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0 at
> Login.MyMB.Lucene.Client.LuceneArticoliSearcher.GetListaArticoloXRicercaAvanzataConRicercaSemplice
> (System.Collections.Generic.List1[T] listParametri) <0x224add0 +
> 0x001bb> in
> <8f49891e0f0546e185aba7424d294ef7#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
> at
> Login.MyMB.Lucene.Client.LuceneArticoliSearcher.GetListaArticoloConRicercaSemplice
> (System.Collections.Generic.List1[T] listParametri) <0x224afbc + 0x0009f> in
> <8f49891e0f0546e185aba7424d294ef7#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0 at
> MyMB.Forms.RicercaLucene.RicercaArticoloLucene.GetListaArticoliXRicercaSemplice
> (Login.MyMB.Interface.IAmbiente ambiente,
> Login.MyMB.Lucene.Client.LuceneArticoliSearcher las,
> System.Collections.Generic.List`1[T] ListParametri, System.Boolean
> isAbilitataRicercaBarcode) <0xe47fc0 + 0x000e7> in
> <f1bb3149abe145459612794f1a096634#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
> ..............................._
> At the link
> [https://docs.microsoft.com/it-it/xamarin/ios/internals/limitations] , I
> found the problem cause (I suppose...):
> _Value types as Dictionary Keys Using a value type as a Dictionary<TKey,
> TValue> key is problematic, as the default Dictionary constructor attempts to
> use EqualityComparer<TKey>.Default. EqualityComparer<TKey>.Default, in turn,
> attempts to use Reflection to instantiate a new type which implements the
> IEqualityComparer<TKey> interface. This works for reference types (as the
> reflection+create a new type step is skipped), but for value types it crashes
> and burns rather quickly once you attempt to use it on the device.
> Workaround: Manually implement the IEqualityComparer<TKey> interface in a new
> type and provide an instance of that type to the Dictionary<TKey, TValue>
> (IEqualityComparer<TKey>) constructor._
> So, what can I do? Thank you in advance, Enrico Caltran +393357485560
> [[email protected]|mailto:[email protected]]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
