On 15/08/2011 18:08, Mattias Gaertner wrote:
Correct. One for the scanner that scans the compiler directives and
extracts the "cleaned source" and one for the parser that reads the
pascal.
Additionally the codetools caches the file sources (i.e. the files
converted to UTF-8).
The biggest part of the files are kept in cache and closing the
project does not free this cache.
so there we go. looking at the numbers I got from the memory manager:
41870000 open lazarus, with about a dozen units - close one unit,
to trigger the output
198591312 open 450 univint - close one unit, to trigger the output
63014880 close all 450 univint => ok so some meory was kept
The 450 files covered 16.7 MB text.
After they were closed, all but 21.1 MB were freed. Given that it will
take a bit of overhead to store the data, given that session info is
stored too..... I believe the numbers match pretty well.
I would say all memory is accounted for.
As for why memory returned to memory manager, does not get back to the
OS (apparently not even when using cmem...) no idea. But memory is
definitely returned to the mem manager.
As for the issue Ludo reported with QT, and requiring even a reset of
his system. *IF* any handles or other resources of the widgetset (not
the lazarus part, but the actual QT or GTK lib or w32) are leaked, then
it needs to be traced. (btw there were people with issues on win98, so
it could be).
But such leaks, would be necessarily be likely to be noticeable as huge
memory consumers.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
