[fpc-devel] Re: Compiler bottlenecks

[Jonas Maebe]

Hans-Peter Diettrich wrote on Wed, 14 Jul 2010:

> Marco van de Voort schrieb:
>> Mapping does not change that picture (the head still has to move if you
>> access a previously unread block).  Mapping mainly is more about -  
>> zero-copy access to file content
>> - and uses the VM system to cache _already accessed_ blocks.
> - and backs up RAM pages by the original file, they never will end  
> up in the swap file.

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.

> 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.

> 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


Jonas

PS: please update the subject when changing the topic

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.