Poor NetObjectCache performance with PCL

[ezverev]

The NetObjectCache is very humble in the matter of relying on the .NET ref tracking. I am not familiar with the CF limitations but why did you hit all the PCL world the same way?

#if CF || PORTABLE // CF has very limited proper object ref-tracking; so instead, we'll search it the hard way
                index = list.IndexOfReference(value);
#else

[mgravell]

Because the API that I would need to do a dictionary based check using reference semantics: didn't exist on those runtimes. If you have an alternative proposal, I'm all ears. On 12 Dec 2017 4:59 p.m., "Zverev Eugene" <notifications@github.com> wrote: The NetObjectCache is very humble in the matter of relying on the .NET ref tracking. I am not familiar with the CF limitations but why did you hit all the PCL world the same way? #if CF || PORTABLE // CF has very limited proper object ref-tracking; so instead, we'll search it the hard way index = list.IndexOfReference(value); #else — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#330>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsKs6kdph1MNnB-iOGbYQzaxCldQpks5s_rDjgaJpZM4Q_TRr> .

[ezverev]

At this moment I am using generic ref tracking code you provided for the full .NET stack i.e. Dictionary strategy with the ReferenceComparer.Default for quite some PCL profiles (24, 32, 111, 158, 255) and it seems to work as intended.

I mean for myself I just commented out the || PORTABLE condition and it compiles and works fine with my PCL projects.

[mgravell]

feel free to do that :) the vast multitude of PCL combinations and permutations is not my strong suit

…

On 12 Dec 2017 7:13 p.m., "Zverev Eugene" ***@***.***> wrote: At this moment I am using generic ref tracking code you provided for the full .NET stack i.e. Dictionary strategy with the ReferenceComparer.Default for quite some PCL profiles (24, 32, 111, 158, 255) and it seems to work as intended. I mean for myself I just commented out the || PORTABLE condition and it works fine with my PCL projects. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsBQUQ4nTMS7cbR7q79965TeVNMbDks5s_tBKgaJpZM4Q_TRr> .

[ezverev]

As long as the Dictionary strategy with the ReferenceComparer.Default compiles fine in the PCL context, would you agree to change the #if CF || PORTABLE compiler condition into #if CF condition and a run-time option which would allow the client to opt-in for the Dictionary variant explicitly?

[mgravell]

if the reference comparer works as expected, I don't see a huge use for the runtime option to be honest. Is it ever expected not to work?

…

On 13 Dec 2017 1:11 p.m., "Zverev Eugene" ***@***.***> wrote: As long as the Dictionary strategy with the ReferenceComparer.Default compiles fine in the PCL context, would you agree to change the #if CF || PORTABLE compiler condition into #if CF condition and a run-time option which would allow the client to opt-in for the Dictionary variant explicitly? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsFQ6HU2NtmmCtQ_9ODV-OlRAlA6cks5s_80NgaJpZM4Q_TRr> .

[ezverev]

I do not think that removing this particular compiler condition would hurt anyone. And it will definitely make PCL users happier.

I've met cases when a valid PCL was referenced by Windows Phone 8.1, compiled and debugged well but failed to pass the API utilization check which is mandatory when uploading the package to the store.
Those cases have nothing to do with our case but they make me always doubt :)