But interestingly I tested this same procedure under Delphi 7 as an exercise to become familiar with SamplingProfiler, and in my tests the exception frame overheads were insignificant.

The time spent on the “end” statement in DoSomething1 varies between 0 and 11%.

I tested with array sizes from 40,000,000 to 200,000,000 integers, with the following typical number of samples for each array size:

Array size: 40M 80M 200M
DoSomething1 105 212 544
DoSomething4 104 211 539

So it seems to me that with Delphi 7 it’s not worth the disadvantages of moving the exception to a procedure.

Or am I missing something? (The “stack setup” line did not appear in any of my profiling, nor did the “case of” line for DoSomething4).

By dealing with the tough questions, in the same way that they would occur to another developer, you make the task of optimizing seem obvious and natural.

Actually saying that a CreateFmt would be the first fix, but then explaining why it won’t help in this case, is perfect.

The approach I’d have taken would have been to have a utility function that returns the Exception to be raised.

ie: line 105 to read
raise CreateUnsupportedException(what)

and defined as
function CreateUnsupportedException(what : TDoWhat): Exception;
begin
Result := Exception.Create(‘Unsupported: ‘+GetEnumName(TypeInfo(TDoWhat), Integer(what)));
end;

Wouldn’t that still remove the Sting cleanup code into the function but also allow the compiler to “see” the raise.

That’s something that I really miss in Delphi. You can’t give the compiler a hint that a procedure never returns. C++0x has something for this but Delphi doesn’t. Maybe somebody should file a feature request in QC.