[fpc-devel] FPC/Lazarus Rebuild performance

[Marco van de Voort]

In our previous episode, Martin Schreiber said:
> > 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.
> 
> Agreed. My opinion is that before we start to implement difficult and 
> error-prone multi-threading into FPC we should find out why the hell Delphi 7 
> can compile so much faster and produces even better code?

I partially agree with you in the fact that the exact reasons are not known.

I'm no expert on profiling the compiler, but if I read the various threads
over the years I see defensive and conflicting statements:

In discussions with Hans, it is said that I/O is not a factor, since after
one run everything is cached anyway, and then in this thread I/O is to blame
for a huge difference in speed.

The same with the fact that we use shortstring for performance in many
places where delphi in fact allows longer mangled names and is faster.

That leaves the maintainability bit. I think that is certainly true,
and it probably can be tweaked to be a bit better. It won't be easy though
and is more likely to be a lot of things that add a little than few that
matter a lot. Which makes it a permanent positions instead of a one-off
effort. Any takers?

As far as the I/O performance discussion goes, some observations:

- To find something interesting, probably the test has to be done for
  various sizes of code. To see if maybe some startup factor (Rather than
  actual processing) is a cause.
- FPC has to read at least twice the number of files (.ppu/.o). So if
  opening or number of files in the dir path is a factor, it will do 
  worse by default. 
- Possibily, a defaultly installed windows searches through a larger unit
  path (more dirs, more file) than Delphi _default_
- For that to be found, more has to be known about dcc.cfg during the 
  tests.
- THis means that tests will have to be repeated with various sizes
  of unitpath trees (both dirs and files) to see if this is a discussion.
- Most profiling recently afaik has been done by Jonas, and thus not
  on Windows. Yet the delphi comparisons are on windows. 
- Actually linking should be avoided in the test. It might obscure
  things.