[fpc-devel] Alternative parsers

[Michael Van Canneyt]

On Wed, 20 Oct 2010, Alexander Klenin wrote:

> On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
> <michael at freepascal.org> wrote:
>>> 2) I'd say that at least half of his mistakes could be avoided
>>> by better code structure of FPC -- he was really uncomfortable
>>> using strange records and pchars instead of normal objects and strings.
>>
>> That has nothing to do with code structure, but with efficiency.
>
> While it may be true that records/pchars increase efficiency,
> they also certainly _are_ an essential part of the code structure.
> And the price paid for whatever efficiency gains they bring
> is reduced maintainability of code.
>
>> pchar and records are much faster than objects and strings.
>> This has been established empirically a long time ago by the compiler
>> developers. Speed of the compiler is an important factor, so records and
>> pchars are used.
>
> 1) I have serious suspicions that compile time on modern processors
> is dominated by linking and I/O.
> At least this is certainly true for FPC on Windows case.

But not on Linux. Even so, it doesn't matter. If linking is slow, 
it doesn't mean the rest should also be slow. What can be optimized, must be
optimized.

> 2) I may believe that records are faster then classes,
> but if they are faster then objects, then this is a compiler problem,
> since there should be literally no difference except the VMT pointer
> memory overhead. Actual usage of virtual calls may cause a slowdown,
> but it also may cause a speedup if it replaces a 'case' statement,
> which is usually so.

The VMT is not the point.

Objects are zeroed out. Records are not. There have been various pleas for a
faster fillchar() on this mailing list, and they are not without reason.

> 3) As for strings, I can see that the overhead may be substantial,
> but that does not mean one have to roll back all the way down to raw pointers.
> Atomic strings with memory pools, for example, might be a good alternative.

There was no 'roll back'. Originally, there were no ansistrings, only
shortstrings, so the compiler was written with pchars.

Ansistrings have serious overhead associated with them, so when they 
appeared, they were not used.

If you need more convincing: the contnrs unit contains 2 hash classes.
one based on ansistrings, one with pchars and shortstrings. 
The pchar version is easily 20% faster. It comes from the 
compiler code and was written specially by Peter Vreman.

Try and improve that class with ansistrings. If you succeed, 
only then we can start making a case for using them in the compiler.

>> So with your last argument you actually strengthen Florians case.
>
> I am not so sure, it looks a lot like a premature optimization to me.

Not 'premature'. It was done after heavy profiling of the compiler,
and the speed improvements were very noticeable.

It sounds like you give us little credit. Most things happen for a reason;
You just don't know the reason.

Michael.