On 29/08/14 23:05, cj wrote:
> I think this problem has been raised on a number of occasions,
> probably for more than a year. The comment that has come back is that
> RISC OS has appalling memory management routines and not much can be
> done. Many other apps manage to release their DAs when documents are
> closed.
Right, well there are a few things to note here.
NetSurf deliberately does not free memory for documents as soon as the
window is closed, or the page is navigated away from.
It keeps things around, because if they are needed again it is much
faster. For example, if we have a JPEG image or CSS file, and then move
to another page using the same resource later, it's a waste of time to
download it again, and parse/decode all the data once more.
So we would not expect to see memory usage drops to occur exactly in
time with windows/tabs closing, or pages being navigated away from.
However, memory for cached content[1] is freed and the user can control
how aggressively it is freed. There is a config option to set the size
of the memory cache. The way NetSurf works, iirc, is every 10 seconds
it checks to see if the amount of memory it has in use due to cached
content exceeds this limit. If it does exceed this limit, it will look
for any content that is currently unused in any open window and free it.
Note that if all current content across your windows/tabs require
content cache that exceeds the cache limit, it won't be able to free
things, or stuff would no longer be available to be shown in the windows.
(Actually image caching is handled specially. Once decoded, a JPEG,
image of a few hundred kilobytes can balloon to many megabytes. If the
memory usage is above the configured limit, NetSurf can free the decoded
version of the image, even if it's currently used on screen. After
that, if NetSurf needs to redraw the image, it has to decode it again
from the source data.)
So that's how NetSurf deals with memory. On RISC OS you have a further
issue. NetSurf uses UnixLib, which implements the memory allocation
stuff using DAs. If a DA contains contents 1, 2 and 3, and they sit in
memory like this
111111222222222222222333333
and NetSurf says it wants to free the allocation for 2, the area now
looks like this
111111 333333
The space between 1 and 3 is not used by NetSurf any more but on RISC
OS, it isn't available for use by other apps. Next time NetSurf
allocates some memory it might not be given the space between 1 and 3,
but something beyond 3, causing the DA to gow.
I think UnixLib can reduce the size of the DA, when the last 64 Kb (or
something) is unused, but in practice that never happens.
If UnixLib used sparse DAs, then the unused memory between what
NetSurf's using would be available for other apps.
Finally, I must say, please create bug reports for issues like this,
with log files. If for example, we're leaking DOM trees right and left,
it will be clear for the log data and we can fix it. Without hard
information, we're only guessing.
[1] By content, I mean any resource like an HTML file, CSS, Images, etc.
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
No comments:
Post a Comment