[fpc-devel] Memory consumed by strings
Mattias Gaertner
nc-gaertnma at netcologne.de
Sun Nov 23 13:19:36 CET 2008
On Sun, 23 Nov 2008 13:35:07 +0200
listmember <listmember at letterboxes.org> wrote:
> > Do a 'find declaration' on an identifier, that does not exist. This
> > will explore all units of the uses section.
>
> Now I see what you mean.
>
> But, isn't this a design-choice; caching all sources in memory for
> speed reasons, as opposed to on-demand opening and closing each file.
The codetools do almost everything on demand.
Needed sources are parsed, put together (include files) and cleaned
from dead code (IFDEFs), trees are built and find declaration results
are cached. This costs a lot of time (more than the compiler doing
the same). But if something changed the codetools know what to
rebuild while OTOH FPC has to rebuilt everything. The naked source
itself normally takes less than 25%.
For example: You can change the declaration of 'integer'. FPC would now
need to recompile almost every unit. But you will hardly notice
much work of the codetools.
These dependencies are complex and require exclusive access. The
memory belongs to the program, the source files can be changed by
anyone.
Therefore the files are kept in memory and auto reloaded if they
change on disk.
> Still. If that is how it works, it is how it works.
Many applications use strings for text files.
As soon as they don't fit into the CPU cache you get a performance
decrease.
Mattias
More information about the fpc-devel
mailing list