[fpc-devel] FPC/Lazarus Rebuild performance

[Dimitri Smits]

----- "Florian Klämpfl" <florian at freepascal.org> schreef:

> Am 11.09.2010 20:50, schrieb Martin Schreiber:
> > On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
> >>
> >> What machine? Because with hot disk cache, I just build MSEide in
> about
> >> 10 s (15 s cold) on W7 64 Bit:
> >>
> > The same as for all other tests,
> > win2000, AMD Athlon XP 3000+, 1GB RAM
> > 
> >> ...
> >> Linking mseidefp.exe
> >> 308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes
> data
> > 
> > Then Delphi7 probably uses about 1 sec on your machine. ;-)
> > 
> 
> ...
> mseide.pas(63)
> 280491 lines, 2.18 seconds, 2110568 bytes code, 752073 bytes data.
> 
> Anyways, before this ends in an endless discussion: if anybody is
> interested in improving FPC compilation speed (for my needs is
> sufficient) and have a look at fillchar and, have a look at FPC's
> unit
> loading algorithm (not the actual i/o itself but how all the symbols
> classes etc. are restored). This two points are bottlenecks which
> might
> help when they are improved, though it's pretty unlikely that this
> will
> improve things more than a few percent.

I am not as intimately familiar with the compiler internals as most of you, but the writing/reading of those .ppu files looks to me like a prime candidate.

other things that I do not know if they are already implemented this way:
1) if the .ppu/.ppl + .o are merged and they give better results then why not go the extra mile and implement packages (or at least the .dcp)? Although I fail to see why (except for linking) both have to be opened during compilation. With packages I mean the .dcp/.bpl equivalent.
It is my understanding that .dcp is like a .lib + all the stuff in the unitinfo (.dcu / .ppu), and ofcourse the more simpler .bpl = .dll "with extra's". That way, you need to dive into much less files.

2) when fetching / checking the files, does it happen according to the unit & include paths and those paths appended by targetos en architectures for every file?
Wouldn't it be more efficient to fetch/cache some dir-info first for all files in those dirs and then fetch the necessary info from there? For instance: get filenames + size + timestamp for all .ppu files or .pas files first.

3) It is my understanding that the .ppu structures are written with size-footprint in mind, not processing efficiency? Maybe the structures need changing too?

kind regards,
Dimitri Smits