[fpc-devel] Need advice for refactoring

[Hans-Peter Diettrich]

Florian Klämpfl schrieb:

>> For profiling and debugging I want to have both the old and new code in
>> the same executable file
> 
> I don't think this is a good idea.
> 
> My proposal is:
> - make a proof of concept for a part of the parser, e.g. ptype.pas, then
> we profile the old and the new compiler with valgrind with code which
> stresses this part.
> - then we decide if it's worth to continue

IMO we have to identify the critical parts of the parser first 
(performance wise), and benchmark otherwise identical code (not trunk 
vs. branch). I'm willing to spend some time with refactoring parts of 
the parser in various ways, until we can agree about an acceptable model.

One working model would be a SVN parser sub-project, so that multiple 
parser models could be developed and tested in parallel, with syncing 
reduced to the units in that project. The same could be done for an 
future threaded approach.


>> For first results see the dodi/parser_rewrite branch.
> 
> Please try to use an indention and coding style as the other compiler
> sources do.

For now I wanted to retain the original indentation, for best SVN merge 
compatibility. Since the indentation width differs even within single 
subroutines, I'd like to reformat all touched units, using the Lazarus 
JCF formatter, so that indentation will not be an issue any more.


> I think also that a complete OOP approach should be used and: design it
> with multi threading in mind. Having a scanner/parser where multiple
> instances can be run at the same time would be a great benefit and I'am
> pretty sure that it will make it into fpc trunk.

An OO move can be done independently from any other refactoring. In a 
first step it should be sufficient to convert all current procedures 
into methods, and the global links into class members. All that is not 
related anyhow to my parser refactoring, but I can start such a new 
project on request. Once it has been accepted or rejected, I can restart 
or continue the parser refactoring accordingly.


Possibly the decision for a threaded model should be taken even before 
any refactoring in that direction, when threads require a very deep 
refactoring. I never wrote complex threads myself, dunno about the 
implications on all the related classes like nodes, procedures, modules, 
optimizer, code generators...

I'd recommend that some threading expert prepares such a refactoring, so 
that I can learn more about the specific coding requirements. The mere 
conversion of procedures into methods, and variables into fields or 
threadvars, won't help much, I fear.

DoDi