[fpc-devel] FPC/Lazarus Rebuild performance

Marco van de Voort marcov at stack.nl
Sun Sep 12 18:39:25 CEST 2010


In our previous episode, Dimitri Smits said:
> > 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???)

It's worth checking out. (writing in general), but I don't expect the
difference to be shocking. If only because typically many more .ppu are read
than written.

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

To my best knowledge that is incorrect. Delphi uses the .dcu's (debug or
not), and only preloads the .dcp that are in the "runtime packages" list
when "compiling with packages" is checked. 
 
> >   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.

For benchmarking: yes. It would actualy be interesting to learn such info,
since generally I've only regarded command like "make all" in the past.

There, Windows (time) : linux (time) is about 2:1, but I always blamed the
bulk on this on the slower startup time of windows exes. Such benchmarks
could confirm (or dispell) that assumption.



More information about the fpc-devel mailing list