If I'm not mistaken, the additional memory used by a larger list, minus the objects referenced by said list, is quite minimal - perhaps nothing more than a stored count. A list with a count of one million, but all of the elements pointing to the same object, will consume no more memory than a list with a single element pointing to said object,
The main problem is the materialization of all those objects, to which you have a number of solutions:
refine the stored procedure, or
have your repository return IQueryable<T> backed by a database LINQ provider, on which you could use the Queryable extension methods which would be converted to SQL by the provider.
but obfuscating the intent of your code by avoiding LINQ and foreach seems rather pointless to me.
Update: I've just looked at the definition (.NET Framework) of List<T>, and none of the fields consume more memory as the size of the list grows (unless T is a value type).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If I'm not mistaken, the additional memory used by a larger list, minus the objects referenced by said list, is quite minimal - perhaps nothing more than a stored count. A list with a count of one million, but all of the elements pointing to the same object, will consume no more memory than a list with a single element pointing to said object,
The main problem is the materialization of all those objects, to which you have a number of solutions:
IQueryable<T>backed by a database LINQ provider, on which you could use theQueryableextension methods which would be converted to SQL by the provider.but obfuscating the intent of your code by avoiding LINQ and foreach seems rather pointless to me.
Update: I've just looked at the definition (.NET Framework) of
List<T>, and none of the fields consume more memory as the size of the list grows (unlessTis a value type).