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

DataServiceClient - Support lazy and unitialized DSC<> properties on proxy. #662

Open
uffelauesen opened this issue Aug 5, 2016 · 0 comments

Comments

Projects
None yet
4 participants
@uffelauesen
Copy link

commented Aug 5, 2016

*Models with entities having many DataServiceCollection<> typed properties exhibits very poor performance during GET operations. The reason seems to be the default CodeGen'ed proxy will do eager initializing of all collection properties. This is a waste of resources and can lead to OutOfMemory exceptions and overall bad performance. *

Assemblies affected

WCF Data Services Client 5.7.0.

Reproduce steps

The simplest set of steps to reproduce the issue. If possible, reference a commit that demonstrates the issue.

Expected result

Performance of new DataServiceCollection<>(query/Ienumerable) would be comparable to that of query.Execute()/ODataReader with only a small overhead.

Actual result

It is taking 50 times longer than query.Execute(). - depending on your model. OutOfMemory exceptions are thrown when fetching 100.000 entites of a type having around 100 DatServiceCollection<> typed properties.
Here are some real measurements of time taken to GET 50.000 File entities (having 125 navigation properties of the DSC type).

4,9716813 seconds. Reader (materialize=True). Count=50000
30,3644236 seconds. DataServiceCollection (trackingMode=None, mergeOption=NoTracking). Count=50000
34,3648641 seconds. DataServiceCollection (trackingMode=None, mergeOption=OverwriteChanges). Count=50000
34,9383197 seconds. DataServiceCollection (trackingMode=None, mergeOption=PreserveChanges). Count=50000
35,4712147 seconds. DataServiceCollection (trackingMode=None, mergeOption=AppendOnly). Count=50000
163,8808292 seconds. DataServiceCollection (trackingMode=AutoChangeTracking, mergeOption=NoTracking). Count=50000
166,7953488 seconds. DataServiceCollection (trackingMode=AutoChangeTracking, mergeOption=OverwriteChanges). Count=50000
164,3714063 seconds. DataServiceCollection (trackingMode=AutoChangeTracking, mergeOption=PreserveChanges). Count=50000
166,4116248 seconds. DataServiceCollection (trackingMode=AutoChangeTracking, mergeOption=AppendOnly). Count=50000

Additional details

You will need a rather large model with entities having many DataServiceCollection<> properties to reproduce this. The issue seems to be related to building of the observer graph that end up having a lot more in it than desired due to the DataServiceCollection<> properties never being null and then gets included in the graph even when they shouldn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.