[fpc-devel] Re: Compiler bottlenecks

Hans-Peter Diettrich DrDiettrich1 at aol.com
Thu Jul 15 03:55:07 CEST 2010

Jonas Maebe schrieb:

> Apart from specific scenarios, memory mapping can easily be slower than 
> direct reads. The main reason is that you get round trips to the OS via 
> hardware interrupts whenever you trigger a page fault, instead of doing 
> one or more (relatively cheap compared to interrupts) system calls. The 
> potential savings of a few memory copies, especially for files in the 
> range of 2-500kb, is very unlikely to compensate for this.

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.

>> I see the biggest benefit in many possible optimization in the scanner 
>> and parser, which can be implemented *only if* an entire file resides 
>> in memory.
> Then just read it into a buffer in one shot.

That's just what I suggested, for a first test :-)

>> When memory management and (string) copies really are as expensive as 
>> some people say, then these *additional* optimizations should give the 
>> really achievable speed gain.
> 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...


More information about the fpc-devel mailing list