On Mon, 30 Jul 2018, J. Gareth Moreton wrote:
On Mon 30/07/18 01:58 , Ben Grasset
operato...@gmail.com sent:
I was even able to successfully actually
fix some of the leaks, but others
boiled down to a "node" being created as
a local variable in the middle of
some 1000+ line method, getting assigned
to the "left" or "right" property
of some other globally visible node, and
then never being freed.
To add to that, some of then actually
*could not* be freed even when I
tried to do so without raising an
untraceable access violation later in the
compilation process, also, which means
the compiler is basically knowingly
relying on undebuggable undefined
behaviour in multiple places that could
easily be affected or altered by
anything else anywhere else in the
codebase at any time.
The way-too-short, highly undescriptive
naming of variables doesn't
exactly help, either! "hp" and "p" are
not good variable names. They really
aren't!
Overall, I'm not trying to put blame on
anyone in particular here, but as
someone who loves using FPC and would
like to see it continue to grow, it
would be nice if we could collectively
address some of these basic,
fundamental issues (which I'd be happy
to help with myself, of course.)
I too love Free Pascal and seek to improve
it. If you've found a fix, by all means
submit it as a patch in the bug tracker.
I've noticed that the compiler doesn't use
try...finally blocks to help with freeing
blocks. I'm not sure why this is the case,
but might be speed related.
Yes. try/finally blocks cause *tremendous* slowdown.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
