Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poor NetObjectCache performance with PCL #330

Open
ezverev opened this issue Dec 12, 2017 · 6 comments
Open

Poor NetObjectCache performance with PCL #330

ezverev opened this issue Dec 12, 2017 · 6 comments

Comments

@ezverev
Copy link

ezverev commented Dec 12, 2017

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
Copy link
Member

mgravell commented Dec 12, 2017 via email

@ezverev
Copy link
Author

ezverev commented Dec 12, 2017

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
Copy link
Member

mgravell commented Dec 12, 2017 via email

@ezverev
Copy link
Author

ezverev commented Dec 13, 2017

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
Copy link
Member

mgravell commented Dec 13, 2017 via email

@ezverev
Copy link
Author

ezverev commented Dec 14, 2017

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants