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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel