Am 08.07.2011 12:05, schrieb Jonas Maebe:
However, looking at the generated assembly, I can't believe there
isn't a more efficient way to handle the implicit try-finally. It
feels to me like that is where the problem is. There is a lot of code
and several function calls that go into implementing that implicit
'finally' block. There's got to be some way to decrement the refcount
even when there are exceptions but without so much overhead. It would
require changes to the exception handling mechanism though. Here my
knowledge runs out.

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
a) support for generating EH frames for all platforms (it's currently
only supported for a number of i386 and x86-64 platforms)
b) support for parsing EH frames on all platforms and performing
exception handling based on that

This is definitely something we want, but nobody has found the time yet
to implement it.

Around a year ago I've experimented with using SEH on Windows (I have not reached a working state back then). It's on my list to revive this again, but before that I want to have Delphi compatible generics and extended RTTI with attributes working :D

Regards,
Sven
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to