[fpc-devel] FPC/Lazarus Rebuild performance

[Michael Van Canneyt]

On Sat, 11 Sep 2010, Sergei Gorelkin wrote:

> Jonas Maebe пишет:
>> On 11 Sep 2010, at 12:23, Martin Schreiber wrote:
>> 
>>> or it isn't true that FPC bottleneck is disk IO. Are we absolutely sure 
>>> about the bottleneck?
>> 
>> I'm quite certain that there are many reasons that FPC compiles more slowly 
>> than Delphi. The bottlenecks probably also vary from platform to platform 
>> and from compilation scenario to compilation scenario. I'm quite sure there 
>> is not a single thing you can "fix" and suddenly get compilation speeds in 
>> the same ballpark as Delphi 7 (how does the compilation speed of current 
>> Delphi's compare to Delphi 7 btw? I read that Delphi XE compiles much 
>> faster than Delphi 2010 in some cases, but I did not see comparisons to 
>> Delphi 7).
>> 
>> One thing that could be done is adding a linear scan register allocator (it 
>> would result in slightly worse code than the current register colouring, 
>> but it executes more quickly).
>> 
>> Going further, general restructuring of the compiler for compilation speed 
>> reasons would only be acceptable if it does not negatively impact the 
>> maintainability. There is a reason why we can support 6 architectures and 
>> umpteen OSes in the compiler with only a handful of people.
>> 
>> 
> One idea that comes at this point is to put PPU data directly into object 
> files, so the number of output files is reduced plain twice. The PPU data 
> could be placed into a section that is ignored by linker. However I don't 
> know is this is possible for all platforms.

Not each platform may support this, so if you want to go down this path, 
why not do the opposite, as Delphi ? Putting the .o data at the end allows 
the compiler to simply not read that data when reading the PPU. 
Only when actually linking do you need to extract all .o data from the ppus.

Michael.