Hello,

Could you implement a dedicated exceptaddr frame creation for raise statements? Because now if raise uses some ansistring constructor, it automatically creates exception frame for the whole procedure where raise was placed. But in most cases exception is not raised and exception frame becames a burden for the whole procedure, especially if ansistrings generally were not used.

Right now I have a "on-the-knee" solution - I'm just creating a local subprocedure called like "doraise" that just raises an exception. This way exception frame is not created in the main procedure, but is created "in time" when the exception raise is needed.

This is maybe not a "general case optimisation", but it is an obvious way to sped up things if exceptions were used.

Best regards,
Aleksey

The frame will always be created. As soon as ansistrings is used in a procedure, an exception frame is created in a procedure - always. Even is no raise statement is present (an exception could e.g. be raised in a called procedure).

Michael.

Hello,

I think you have not got the idea.

I mean, if I write something like this:

resourcestring
  ErrMsg = 'aaabbbccc';
procedure Test123;
begin
     if (not Success) then
       raise Exception.create (ErrMsg);
    ...do something a little...
end;

Stackframe will be created for the whole Test123 and its overhead will be applied to "...do something a little..." in all the cases.

But if I write in this way:

procedure Test123;
  procedure doraise;
  begin
    raise Exception.create (ErrMsg);
  end;
begin
     if (not Success) then
       doraise;
    ...do something a little...
end;

Overhead is issued ONLY if Success = False. In all other cases "...do something a little..." executes without ANY unnecessary overhead.

Best regards,
Aleksey

I see your point, but implementing this especially for raise seems to require a lot of effort and the speed gain will be little ... especially because the 1.1 compiler has an optimized exception frame handling.

The frame will always be created. As soon as ansistrings is used in a procedure, an exception frame is created in a procedure - always. Even is no raise statement is present (an exception could e.g. be raised in a called procedure).

Hmmm, please reread the quoted original email, Michael :)!

OK, I see what you mean now, yes, in this case the code will be faster. I'm not sure whether this is possible, this is something for Florian Klaempfl to decide :/

Michael.

Yes. I misunderstood what he wanted to say :/

Michael.

But what when you have:

case value of
1 :
ansistring operation
2 :
ansistring operation
3 :
ansistring operation
else
shortstring operation
end;

Then with having the exceptionframe around the smallest possible ansistring operation it will generate the code 3 times.

It would need some addtional information:
When compiled with -OG it would be worth the effort in this case.

Nevertheless, it would require heavy changes in temp. ansistring generation and raise
code generation, so Aleksey's workround seems to me the only solution.

Hello,

I'm not talking about such cases. I meant only RAISE statement, because its usage denotes an exceptional program's behaviour that is generally rare. And BTW, "case" example you've mentioned if you apply strategy I've proposed will be slow only in loops.

Anyways, I think there is some research needed in this field - optimising stackframes insertion will obviously give a general speedup.

But anyways, "raise" optimisation could be very useful. (in fact, I'm forced to use doraise; procs now, but this is VERY unpleasant).

Best regards,
Aleksey

I totally agree with you but as you may know there are a lot of other things which must be done, so this optimization is postboned by use except somebody provides patch to implement it :/

Hi,

I want to ask about COM objects support status in 1.1 compiler.

you wrote

Hi, I want to ask about COM objects support status in 1.1 compiler.

I compiled several DX programs which use interfaces with the 1.1 compiler and it worked.