Imagine an entity with many properties of type DataServiceCollection<>. As an example - our File entity has 126 Properties of type DataServiceCollection<>
The auto-generated proxy will do eager initializing (as part of the construction process) of all these properties for each File entity returned from the server during the materialization process even when they are not needed (have not been expanded). The overhead of this is massive and can lead to an OutOfMemory exception when a lot a Files are handled. It is also very time consuming.
If I substitute the eager initialization of all DataServiceCollection<> properties (in the proxy/Reference.cs) with lazy initialization (like: p == null ? p = new DataServiceCollection…) the memory consumption is kept at a more reasonable level and I can handle loads of File objects. The overall time consumption is also significantly lower.
This change does however require changes to DataServicesClient/OData.Client, as it currently would just trigger the lazy initialization during GETs. Se here: https://github.com/OData/odata.net/issues/662
Imagine an entity with many properties of type DataServiceCollection<>. As an example - our File entity has 126 Properties of type DataServiceCollection<>
The auto-generated proxy will do eager initializing (as part of the construction process) of all these properties for each File entity returned from the server during the materialization process even when they are not needed (have not been expanded). The overhead of this is massive and can lead to an OutOfMemory exception when a lot a Files are handled. It is also very time consuming.
If I substitute the eager initialization of all DataServiceCollection<> properties (in the proxy/Reference.cs) with lazy initialization (like: p == null ? p = new DataServiceCollection…) the memory consumption is kept at a more reasonable level and I can handle loads of File objects. The overall time consumption is also significantly lower.
This change does however require changes to DataServicesClient/OData.Client, as it currently would just trigger the lazy initialization during GETs. Se here: https://github.com/OData/odata.net/issues/662