CListCtrl item count limitation and memory(RAM) usage

Problem:

I wrote a program that has 10~12 CListCtrls which rows are appending to simultaneously.

I've never deleted old items to limit the row count of listCtrls, and the program has ran for about 1 day.
I've just seen the process monitor and realized that the memory usage increased to 600MB (originally it's about 70~80MBs)

I thought the reason is related with CListCtrls.

Question:

I want to reduce the memory usage to about 100MB.

So, I want to know that:

1. Is there default limitation of CListCtrl's row count, and how much is it?

I heard that there is a limitation of CListCtrl so no need to delete top items manually from one of my teammates.

2. Will the memory usage be reduced as much as I delete top items?

I wonder CListCtrl holds buffer data same as what we can see on UI or it only increases the buffer size like in std::vector.

3. If CListCtrl doesn't realse the buffer which is removed on UI, What is the solution to limit memory usage?

Or maybe the reason of problem is not related with CListCtrl?
I used LVS_EX_DOUBLEBUFFER with CListCtrls.
On the other hand, I used 10-12 file mappings for logging which is about 6MB each. These have been tested so much time, and I believe that there is no memory leaks.

Any answers or references will be appreciate, thanks.

Solution

Like just about anything in computing, there is no guessing involved. A list-view control is no exception to this. There is no default limit, and the control will dutifully store all data you throw at it, until it runs out of system resources. It will not attempt to guess which data you may find important or discardable.

If you need to limit the amount of resources a list-view control consumes, then that's on you. You would have to manually delete items that you know are no longer relevant. How much memory gets released (or if any at all) in response to deleting an item is an implementation detail. You have no control over this.

If you need that kind of control, you would have to relieve the list-view control from managing memory on your behalf. Thankfully, the control provides you with the LVS_OWNERDATA feature, allowing you to manage the backing memory separate from the control, and only telling the control, how many items there are.

This is commonly referred to as a virtual list-view, and you will find countless examples of how to implement one, such as How to Use Virtual List-View Controls.

The LVS_EX_DOUBLEBUFFER extended list-view style is unrelated to any of this. It pertains to rendering only, and adds a one-time constant overhead in terms of system resources.