Hans-Peter Diettrich wrote on Thu, 15 Jul 2010:
Jonas Maebe schrieb:
[snip]
When the file resides in the OS file cache, no page faults will
occur unless the file was removed from the cache. If not, every
access request has to do disk I/O, resulting in process switching
etc., so that the page faults are neglectable.
That is only true if you get at most as many page faults as you
perform "read" system calls.
Then just read it into a buffer in one shot.
That's just what I suggested, for a first test :-)
Just increasing the buffer size by itself does not have any noticeable
effects on the compilation speed (I benchmarked it in the past).
a) the memory management overhead primarily comes from allocating
and freeing machine instruction (and to a lesser extent node tree)
instances
b) the string copy cost I mentioned primarily comes from getting
symbol names for the purpose of generating rtti and assembler
symbol names
May be, we'll see...
Those facts come from profiling runs. That does not mean that nothing
can be optimised in the scanner/parser, but the bottleneck routines I
posted are unrelated.
Jonas
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
