[fpc-devel] Const optimization is a serious bug
Den Jean
Den.Jean at telenet.be
Fri Jul 8 19:59:54 CEST 2011
On Friday 08 July 2011 12:05:02 Jonas Maebe wrote:
> The main problem here is that FPC's exception handling is based on
> setjump/longjump. This technique has a relatively high overhead for
> "try", but low overhead when an exception actually occurs (of course,
> since exceptions are supposed to happen only exceptionally, that's not
> a really good selling point). The main reason we use it is because
> it's easy to implement.
>
> A better approach would be to use SEH-based exception handling (which
> has no overhead at all for "try", and a high overhead in case an
> exception occurs), but that woud require
I strongly prefer the current situation where the occurrence of
exceptions does not incur an important extra overhead compared to
the nominal situation.
In the type of applications I write (Air Traffic Control Radar Screens,
Electronic Strips and System Interfaces) it is considered good practice
to catch exceptions in every procedure because it is a must that
the applications always survive and continue to provide the remaining,
not affected services.(graceful degradation principle)
I do not want any discussions whether catching exceptions is good or not.
If someone thinks otherwise, I do not care at all, do not bother me or
this mailing list.
However what is imperative is that when many exceptions occur, there should
not be a mayor performance penalty. One of the reasons I use languages such
Pascal and Ada for this type of applications, is that they are very fast,
(though I also have foreseen code to shutdown services with too many problems
in a given time frame). So I beg you to leave exceptions as is (please :-)).
kind regards,
Den Jean
More information about the fpc-devel
mailing list