[fpc-devel] FPC/Lazarus Rebuild performance

[Dimitri Smits]

----- "Marco van de Voort" <marcov at stack.nl> schreef:

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

that may be the case for reading, not necessarily for the files being written. 
in ppu.pas, everything you "put" results in a blockwrite of x bytes. Wouldn't a cached memory stream be better, not resulting in those int21h calls or windows equivalent calls?
Haven't looked at .s creation (donno where to start looking, but I guess this is the same???)

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

agreed

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

actually, this is a false statement. The units that come with delphi (rtl and others) are packaged in .dcp (and .bpl). That means that not only those "x2 files", but a factor of those "x2" can be done. Admitted that you probably load "way to much" in some cases as well as that it is not easy to know in what .dcp your needed unitinfo is included. Or at least isn't obvious.

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

in that case, all "external tools" should be avoided.

kind regards,
Dimitri Smits