[Mono-bugs] [Bug 608195] Enumerable.Reverse should be lazier

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Mon May 24 10:25:13 EDT 2010



Jonathan Pryor <jpryor at novell.com> changed:

           What    |Removed                     |Added
                 CC|                            |jpryor at novell.com

--- Comment #3 from Jonathan Pryor <jpryor at novell.com> 2010-05-24 14:25:13 UTC ---
I fail to see how this is a significant change/benefit.

For your example, the current behavior:

    var reversedInts = Enumerable.Range(0, int.MaxValue).Reverse();
    // memory increased by 8GB

For your "improved" example:

    var reversedInts = Enumerable.Range(0, int.MaxValue).Reverse();
    // negligible memory increase

    foreach (int n in reversedInts) {
        // memory increased by 8GB

You're just moving where the 8GB is allocated, you're not reducing or removing
the 8GB memory allocation.  Nor can you remove the 8GB memory allocation -- in
order for Reverse() to work, it needs to find the end of the sequence,
therefore it needs to traverse the entire list.

(OK, I suppose if you wanted to severely tradeoff performance for memory use
you could actually do .Count(), then .ElementAt(), which would keep from
loading the entire sequence into memory at once, but at the cost of N+1
iterations of the sequence, which won't be cheap execution-wise...)

The database case is also ~completely different, assuming Linq-to-SQL or Entity
Framework, as those will use Queryable.Reverse(), not Enumerable.Reverse(),
which will allow the 'reverse' to be handled at the SQL level, not in managed
code. If you're intermixing Linq-to-SQL and Linq-to-Objects you might have a
case here, but you can't otherwise avoid the requirement that
Enumerable.Reverse() store the entire sequence contents.

Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the mono-bugs mailing list