[fpc-devel] Need advice for refactoring
DrDiettrich1 at aol.com
Sat Jul 17 13:48:14 CEST 2010
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.
More information about the fpc-devel