[Lazarus] RE : RE : RE : RE : RE : RE : RE : RE : Console App Development

[Ludo Brands]

-----Message d'origine-----
De : Mattias Gaertner [mailto:nc-gaertnma at netcologne.de] 
Envoyé : lundi 15 août 2011 19:09
À : Lazarus mailing list
Objet : Re: [Lazarus] RE : RE : RE : RE : RE : RE : RE : Console App
Development



Martin <lazarus at mfriebe.de> hat am 15. August 2011 um 17:27 geschrieben: 

>[...] 
> > In the mean time I found where the refcount increases: 
> > DoOpenUnknownFile 
> > ->CodeToolBoss.GetSourceType 
> > ->FCurCodeTool.GetSourceName 
> > ->TPascalReaderTool.BuildTree<- this where the refcount increases to 2 

 

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. 

For example once the codetools have loaded and parsed the classes.pp it is
kept in memory. 

This was so from the beginning (at least since 9 years). 

Of course the RTL and FCL sources grew over the years and so the codetools
need more memory.

 

The other big caches of the codetools are the code nodes. The memory need
varies greatly depending on the code, but they typically need somewhat less
than the sources.

There is a lot of other stuff, but this makes only a few percent. 

 

In my experiments memory fragmentation can tripple the amount of memory
needed by the codetools. 

 

AFAIK the several hundred MB of ram needed by the IDE was no problem yet -
even for student machines.

 

 

Mattias

 

Thanks for that info. That helps a lot.

Figured out in the meantime that indeed TCodeBuffer.Scanner.Src is the one
hanging on to the source after a TCodeBuffer.IsDeleted:=true and that
TCodeBuffer.Scanner.CleanedSrc has, at first sight, another copy of the
source. Is this really a cache and re-used when reopening the file? With the
GTK2 widgedset I see an increase in memory allocated by TCodeBuffer when
opening/closing/reopening the same files.

Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110815/990c9ca9/attachment-0003.html>