On Apr 1, 2013, at 7:51 PM, Natanael <[email protected]> wrote:
> I have a simple app that calls a method in the click event of the button.
>
> As I'm clicking the button the use of memory is increasing and it is not
> released.
How are you tracking memory use? Which memory is constantly increasing and
isn't released?
> I suspect this problem is related to the use of List<T>. The Clear() method
> seems not release the memory.
This is somewhat correct: List<T>.Clear() doesn't release the underlying array,
it just clears the contents:
https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Collections.Generic/List.cs#L172
The end result being that after your `list.Clear()` call, `list._items` will
still contain 5000+ (8192, actually) elements, they'll just all be `null`. You
will need to perform/wait for a GC for the 5000 previously allocated instances
to be collected.
In the case of your sample app, this behavior is actually an optimization. The
first time Class1.Pesquisa() is invoked, the Class1.list._items array will need
to be constantly resized until it contains at least 5000 elements (due to the
`for` loop). (It'll actually contain 8192 elements due to the "double the
previous size" behavior.) The second and subsequent times Class1.Pesquisa() is
invoked, Class1.list._items will not need to be changed at all, and you're just
allocating 5000 ListClass instances (instead of 5000 ListClass instances +
log2(5000) ListClass[] array instances).
This is also documented behavior:
http://msdn.microsoft.com/en-us/library/dwb5h52a.aspx
> Capacity remains unchanged. To reset the capacity of the List<T>, call the
> TrimExcess method or set the Capacity property directly.
If you absolutely need to shrink your List<T> size, you can't just use
List<T>.Clear().
- Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
