[fpc-devel] Alternative parsers

[Alexander Klenin]

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

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

-- 
Alexander S. Klenin