[fpc-devel] Comparison FPC 2.2 - Delphi 7

[Michael Van Canneyt]

On Thu, 5 Jul 2007, Florian Klaempfl wrote:

> Marco van de Voort schrieb:
> >> Op Thu, 5 Jul 2007, schreef Marco van de Voort:
> >>> So we can be short about this issue: want to improve? Start measuring, the
> >>> compiler is just a bloody pascal program.
> >> During the 2.1 cycle, very little attention was paid to the speed of the 
> >> compiler itself. This is because the compiler is fast enough for our 
> >> needs.
> > 
> > Agree fully, but then we should communicate that, (and point people to the
> > profiler) and not blame it on portability beforehand.
> 
> I profiled it some time ago and the compile time is simple spread over
> the compiler. Only two procedures consumed a lot of time: fillchar and
> move. I added the fastmove code at this time because we spend at least
> some time in move.
> 
> In general, we loose there and there 1-2 percent and at the end we're 5
> times slower. Just start with the scanner: we support macro
> replacements, this requires an additional symtable look up for every
> symbol. Continue with PPU loading: we check for endianess when loading,
> requiring additional code. We write two or three files (.ppu, .o and .a)
> instead of one. Our register allocator is more sophisticated and scales
> better. We don't write the machine code directly but generate assembler
> first which can be written as listing, Delphi can't. Several debugging
> formats are supported, different assembler backends and so one.
> 
> None of these things is speed critical but it simply sums up.

Which was exactly my argument: The architecture.

Borland is focused on 1 CPU and 1 toolchain (their own), we are not, 
and we additionally support a lot of extra features which Borland 
does not support. All this shows in the architecture.

One of the reasons Florian profiled it was because Morfik had the same 
problem as Martin has now. He did some minor improvents (15% gain if
I remember correctly ?)

As far as I know, in the end they solved it by creating a background 
thread which just continually compiles all code, so that when the user 
hits 'compile', it's already compiled, thus creating a 'fast' user 
experience...

Michael.