ID:1743714
 
Keywords: list, memory, oview, stats, view
BYOND Version:507
Operating System:Windows XP Pro x64
Web Browser:Chrome 39.0.2171.95
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary: See this post for details.

Numbered Steps to Reproduce Problem:
Simply use oview or view and check the memory for the list stat (make sure you know what it was before). Try freeing or deleting the list and check again.

Expected Results:
For the memory to return to the value it was prior to the use of the aforementioned procs.

Actual Results:
The memory becomes inflated.

Does the problem occur:
Every time? Or how often? Every time.

When does the problem NOT occur? When I don't use the mentioned procs (i.e. never).

Did the problem NOT occur in any earlier versions?
It also occurs in 506.1247.

Workarounds: None.

Additional Comments: Here is a test project. Just use the test_oview verb and watch.
The view/range/etc. procs use a shared memory allocation that gets reused in subsequent calls. Allocating and clearing every time would be grossly inefficient.

However, the internal allocation really shouldn't have any bearing on the list stat. What you may be seeing is that the server also keeps a "static" list with a fixed ID, that gets reused frequently as well.

In any case unless this is building out of control I don't think there's any cause for alarm. The server will tend to allocate memory for a number of tasks where it avoids freeing it again, if it thinks the memory will be needed later on.
In response to Lummox JR
Ah, alright. Thanks for that information.