speed of try-catch

if used the try-catch context, the processing is more quick than not use?

Jochen
Thu Jul 31 00:08:45 CDT 2003

yonggeon kim wrote:

> if used the try-catch context, the processing is more quick than not use?

If you are using the try-catch syntax, then your app is running a little
bit slower than without.
But if en exception is thrown inside the try-catch block, then this
consumes a huge amount of time.

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/useritems/leakfinder.asp

Kim,
Thu Jul 31 01:34:49 CDT 2003

"Jochen Kalmbach" <nospam-Jochen.Kalmbach@holzma.de> wrote in message news:Xns93C948BAC2EE3JochenKalmbachholzm@127.0.0.1...
> yonggeon kim wrote:
>
> > if used the try-catch context, the processing is more quick than not use?
>
> If you are using the try-catch syntax, then your app is running a little
> bit slower than without.


For what? What is the comparative target in your answer?


> But if en exception is thrown inside the try-catch block, then this
> consumes a huge amount of time.

What kinds of excessive consuming arise?

IMO, in the case of comparision of "function returns some values
and their err-handler" and "strategy of try-catch",
the "strategy of try-catch" is much more
faster than as the first one. It is same as the "switch" and
"if-else chain"'s case.

For exam, ( Pseudo code )

class errtype;
class a; // derived from base_type
class b; // derived from base_type
class c; // derived from base_type

// case A
errtype f(){
if( case A ) return a();
if( case B ) return b();
if( case C ) return c();
}

{
errtype ret = f();
if(ret==a) ...
else if(ret==b) ...
...
}

// case B
void f() throw(a,b,c,d,base){
if( case A ) throw a();
if( case B ) throw b();
...
}

{
try{
f();
}
catch(a){}
catch(b){}
...
}

How about this?


S Kim <stkim@yujinrobot.com>

Ivan
Thu Jul 31 01:39:27 CDT 2003

It depends vastly on the programming style you will be using.
Let's make a very simple example [see below, commented here].
In the first case you will have per each complete chain of operations
3 tests for the result code of your worker functions,
while in the second case there is no test if the contract is
that the worker function will throw when something bad has happened.
The resource cleanup is manual in the first case,
while it's 'embedded' in the objects in the second example.
In the first case the programer has to keep track of what is to be freed and
what not,
while in the second case the compiler takes care of the job.
The compiler can be smart about how to keep tral of partially constructed
objects,
while the programmer needs to test explicitely for some
IsReallWorthDestroying(MyResource),
that is often a test for NULL, unless it uses manually scopes.
The cost for keeping track of instances of classes in a given scope is to be
paid
no matter if the `if-succeeded-stair' is used or the `exception-safe-code'
style.
depending on compiler options, you may find that your code has the `call
XXXX!__EH_prolog'
[this is true for x86. for IA64 and AMD64 there is never an explicit prolog
for exception handling]
code in almost each function you've written, thus you are paying the same
cost of exception handling
even if you are not getting any benefit.
As a rule of thumb, you can assume that writing try/catch in your function
is not going to
affect the execution speed of your program.
Pedantically testing error codes instead of using exceptions may introduce
some
complexity in the generated code, and the mainstream code path may result
slower.
It's also true that dispatching an exception is not cheap.
The exception (synchronous with throw/RaiseException, async if you have
native exceptions)
needs one transition in kernel and one transition back to the exception
dispatcher code.
The exception dispatcher code MUST analyze each function on the stack for a
possible filter
wishing to recognized the exception (here I'm intentionally confusing native
exceptions and C++ exceptions as far as terminology is concerned), and as
soon as a filter is found,
if must unwind the stacks for all the encountered scopes.
Basically yur are paying in one shot the cleanup cost
that you would otherwise pay entering and leaving each scope,
plus one U-2-K transition (in the sync case) and one K-2-U transition.

To conclude, exception may lead to a more performant code if:
- they are really used for exceptional cases and not as a substitute of
error control.
- the places that throw the exception are very few (OS-level resource
allocators and nothing much shold throw)
- the places where the exception are caught are few (basically only at the
component boundaries)
- the rethrow paradigm is banned.
- the code is fully designed with exception in mind
(a function should always return void if any error is handled with
authomatic objects and exceptions).

Many may disagree with this, giving different circumstances where each
paradigm is superior
given a set of defined boundary condition. Hopefully I have been able to
give an overview of the problem.


if-SUCCEEDED-stair

HRESULT Funct() {
if (SUCCEEDED(Operation1(&Operation1Result))){
if (SUCCEEDED(Operation2(&Operation2Result))){
if (SUCCEEDED(Operation3(&Operation3Result))){
//
FreeResources(Operation3Result);
}
FreeResources(Operation2Result);
}
FreeResources(Operation1Result);
}
}

exception safe code

void Funct() {

OP_RES_1 Operation1(SomeParam);
Operation1.SomeMethod();

OP_RES_2 Operation2Result(SomeParam);
Operation2.SomeMethod();

OP_RES_3 Operation3Result(SomeParam);
Operation3.SomeMethod();
}

function invoker like

int main(int,char **){
try {
Funtc();
} catch (...) {
}
return 0;
}


--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"yonggeon kim" <ygkim@yujinrobot.com> wrote in message
news:#QhHejvVDHA.2104@TK2MSFTNGP10.phx.gbl...
> if used the try-catch context, the processing is more quick than not use?
>
>

Jochen
Thu Jul 31 03:36:27 CDT 2003

Kim, Seungtai wrote:

> "Jochen Kalmbach" wrote:
>> yonggeon kim wrote:
>>
>> > if used the try-catch context, the processing is more quick than
>> > not use?
>>
>> If you are using the try-catch syntax, then your app is running a
>> little bit slower than without.
>
>
> For what? What is the comparative target in your answer?

Sorry, I do not understand the question...

"try-catch" against "not to use it (means return values)"


>> But if en exception is thrown inside the try-catch block, then this
>> consumes a huge amount of time.
>
> What kinds of excessive consuming arise?
>
> IMO, in the case of comparision of "function returns some values
> and their err-handler" and "strategy of try-catch",
> the "strategy of try-catch" is much more
> faster than as the first one. It is same as the "switch" and
> "if-else chain"'s case.

Äh.......

Just for a small comparsion:
Simple programm with loops 100.000 times gives the following result (debug
build):
try-catch: 416.744016 ms
result-code: 4.591348 ms


As far as I can interpret the numbers it shows me that I will NOT USE try-
catch as "normal result-handling" from methods.


<code>

#include <windows.h>

class CExcatTimeDiff
{
public:
CExcatTimeDiff()
{
QueryPerformanceCounter((LARGE_INTEGER*) &m_BeginTime);
m_EndTime = 0;
m_Frequency = 0;
}
void Begin()
{
QueryPerformanceCounter((LARGE_INTEGER*) &m_BeginTime);
}
void End()
{
QueryPerformanceCounter((LARGE_INTEGER*) &m_EndTime);
}
double GetDiffInMs()
{
if (m_Frequency == 0)
QueryPerformanceFrequency((LARGE_INTEGER*) &m_Frequency);
if (m_EndTime == 0)
End();
return ((double)m_EndTime - (double)m_BeginTime) / ((double)m_Frequency
/ 1000);
}
private:
__int64 m_BeginTime;
__int64 m_EndTime;
__int64 m_Frequency;
};

// #####################################################


class baseExp
{
};

class aExp : public baseExp
{
};
class bExp : public baseExp
{
};

void ThrowFunction()
{
throw aExp();
}

DWORD ResultFunction()
{
return 12; // means aExp...
}



int _tmain(int argc, _TCHAR* argv[])
{
int i;
CExcatTimeDiff timerThrow;
CExcatTimeDiff timerResult;

// try-catch
timerThrow.Begin();
for(i=0;i<100000; i++)
{
try
{
ThrowFunction();
}
catch(aExp)
{
//printf("aExp");
}
catch(bExp)
{
//printf("bExp");
}
}
timerThrow.End();


// result-codes
timerResult.Begin();
for(i=0;i<100000; i++)
{
DWORD res = ResultFunction();
switch(res)
{
case 12:
//printf("aExp");
break;
case 13:
//printf("bExp");
break;
}
}
timerResult.End();


printf("try-catch: %f ms\n", timerThrow.GetDiffInMs());
printf("result-code: %f ms\n", timerResult.GetDiffInMs());


return 0;
}
</code>

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/useritems/leakfinder.asp

Kim,
Thu Jul 31 04:10:07 CDT 2003

"Jochen Kalmbach" <nospam-Jochen.Kalmbach@holzma.de> wrote in message
>[...]
> >> But if en exception is thrown inside the try-catch block, then this
> >> consumes a huge amount of time.
> >
> > What kinds of excessive consuming arise?
> >
> > IMO, in the case of comparision of "function returns some values
> > and their err-handler" and "strategy of try-catch",
> > the "strategy of try-catch" is much more
> > faster than as the first one. It is same as the "switch" and
> > "if-else chain"'s case.
>
> Äh.......
>
> Just for a small comparsion:
> Simple programm with loops 100.000 times gives the following result (debug
> build):
> try-catch: 416.744016 ms
> result-code: 4.591348 ms
>
>
> As far as I can interpret the numbers it shows me that I will NOT USE try-
> catch as "normal result-handling" from methods.
> [...]

I've got the smilar result in my PC(small modified version: throw built-in
type than user-defined type and use "if-else chain" than "switch" )
as your one.

And I agreed your opinion. It's significantly performance difference
in my environments(VC++6.0 enterprese version, Win2K).

There are some questions still remained.

- The other case such as multi level returing case(deep dept),
heavy user defined object returing and comparision, long if-else
chained case,...
- The other environments like gcc, ...
- Implementation defined problem or
basically capsulated program by C++ Standard.

Thanks in advices.


S Kim <stkim@yujinrobot.com>

Kim,
Thu Jul 31 05:54:14 CDT 2003


"Jochen Kalmbach" <nospam-Jochen.Kalmbach@holzma.de> wrote in message
> Kim, Seungtai wrote:
>
> > My results :
> > try-catch: 0.492521 ms
> > result-code: 0.711822 ms
>
> I just want to recall your statment:
>
> <Kim, Seungtai>
> the "strategy of try-catch" is much more
> faster than as the first one. It is same as the "switch" and
> "if-else chain"'s case.
> </Kim, Seungtai>
>
> Especially "is much more faster"...

And after I comments :

"Kim, Seungtai"
> And I agreed your opinion.

in the other article. It's clearly that my first opinion is false.

And in the last articles I assert the another try-catch's
effective point.


S Kim <stkim@yujinrobot.com>

ahoskins
Thu Jul 31 13:06:46 CDT 2003


--------------------
> From: "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com>
> Message-ID: <O22K55yVDHA.3924@tk2msftngp13.phx.gbl>

I have just a couple notes to add.

>
> As a rule of thumb, you can assume that writing try/catch in your function
> is not going to
> affect the execution speed of your program.

Theoretically this is true but in practice it's often not quite, as the
compiler cannot optimize the code
as aggressively with the additional program flow complexity introduced by
exception handling.

> Pedantically testing error codes instead of using exceptions may introduce
> some
> complexity in the generated code, and the mainstream code path may result
> slower.

Exception handling has a higher code size on average than testing error
codes, so you
should see real decrease in complexity before you expect it to be an
improvement.

I still think these conclusions are accurate:

> To conclude, exception may lead to a more performant code if:
> - they are really used for exceptional cases and not as a substitute of
> error control.
> - the places that throw the exception are very few (OS-level resource
> allocators and nothing much shold throw)
> - the places where the exception are caught are few (basically only at the
> component boundaries)
> - the rethrow paradigm is banned.
> - the code is fully designed with exception in mind
> (a function should always return void if any error is handled with
> authomatic objects and exceptions).
>
> Many may disagree with this, giving different circumstances where each
> paradigm is superior
> given a set of defined boundary condition. Hopefully I have been able to
> give an overview of the problem.
>
>
> if-SUCCEEDED-stair
>
> HRESULT Funct() {
> if (SUCCEEDED(Operation1(&Operation1Result))){
> if (SUCCEEDED(Operation2(&Operation2Result))){
> if (SUCCEEDED(Operation3(&Operation3Result))){
> //
> FreeResources(Operation3Result);
> }
> FreeResources(Operation2Result);
> }
> FreeResources(Operation1Result);
> }
> }
>
> exception safe code
>
> void Funct() {
>
> OP_RES_1 Operation1(SomeParam);
> Operation1.SomeMethod();
>
> OP_RES_2 Operation2Result(SomeParam);
> Operation2.SomeMethod();
>
> OP_RES_3 Operation3Result(SomeParam);
> Operation3.SomeMethod();
> }
>
> function invoker like
>
> int main(int,char **){
> try {
> Funtc();
> } catch (...) {
> }
> return 0;
> }
>
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "yonggeon kim" <ygkim@yujinrobot.com> wrote in message
> news:#QhHejvVDHA.2104@TK2MSFTNGP10.phx.gbl...
> > if used the try-catch context, the processing is more quick than not
use?
> >
> >
>
>
>


--
Drew Hoskins, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Bo
Thu Jul 31 14:59:43 CDT 2003


"Arnaud Debaene" <adebaene@club-internet.fr> skrev i meddelandet
news:uPHBDl4VDHA.1620@TK2MSFTNGP12.phx.gbl...
> Jochen Kalmbach wrote:
> >
> > Just for a small comparsion:
> > Simple programm with loops 100.000 times gives the following
result
> > (debug build):
> > try-catch: 416.744016 ms
> > result-code: 4.591348 ms
> <snip>
>

Yes, Jochen just proved that returning 12 is faster than constructing
and copying a class hierarchy, when you don't inline the empty
constructors. I already knew that! :-)

> It's more complicated than that : as Ivan has explained it, actually
> throwing and catching an exception IS very time consuming (at least
in VC6).
> However, in "real" code, exceptions should be... well,
exceptionnal(!),
> which means they should occur only rarely. The idea is that, if no
error
> occurs (majority of cases), exception mechanism is faster than
checking a
> status code. Therefore, if performances are important, you should
use
> exceptions only in those cases where the error is so severe that
> performances are no more of any concern.

Yes, if we instead try code that actually works - meaning *not*
throwing an exception - against code that constantly tests its return
value for errors, the code using exceptions can be simpler, faster,
and easier to get correct.

Consider *not* throwing an exeption 100000 times agains checking
100000 return codes. Guess which is fastest!



Bo Persson
bop2@telia.com



>
> Arnaud
>
>

Jochen
Fri Aug 01 00:38:08 CDT 2003

Bo Persson wrote:

> Consider *not* throwing an exeption 100000 times agains checking
> 100000 return codes. Guess which is fastest!

Maybe you misunderstood something...
Normaly you define only ONE return code which indicates SUCCESS!

So you compare: *not* throwing an exeption 100000 times agains checking
1 return code.

No guess which is faster?

As you can imagine both are almost the same...


But if an exception occurs the simple compare will be faster (or at least
NOT slower) then the try-catch block...

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/useritems/leakfinder.asp

Bo
Fri Aug 01 19:00:25 CDT 2003


"Jochen Kalmbach" <nospam-Jochen.Kalmbach@holzma.de> skrev i
meddelandet news:Xns93CA4DB69591JochenKalmbachholzm@127.0.0.1...
> Bo Persson wrote:
>
> > Consider *not* throwing an exeption 100000 times agains checking
> > 100000 return codes. Guess which is fastest!
>
> Maybe you misunderstood something...
> Normaly you define only ONE return code which indicates SUCCESS!
>
> So you compare: *not* throwing an exeption 100000 times agains
checking
> 1 return code.

Except that the original timing was for calling a function 100000
times, remember. In that case you must check the return code each
time, but only set up an outer try/catch block once.

If everything works as expected, there shouldn't be any exceptions
thrown, so you don't have to catch any exception.

>
> No guess which is faster?


Bo Persson
bop2@telia.com

Jochen
Mon Aug 04 00:35:01 CDT 2003

Bo Persson wrote:

> "Jochen Kalmbach" wrote:
>
>> Bo Persson wrote:
>>
>> > Consider *not* throwing an exeption 100000 times agains checking
>> > 100000 return codes. Guess which is fastest!
>>
>> Maybe you misunderstood something...
>> Normaly you define only ONE return code which indicates SUCCESS!
>>
>> So you compare: *not* throwing an exeption 100000 times agains
> checking
>> 1 return code.
>
> Except that the original timing was for calling a function 100000
> times, remember. In that case you must check the return code each
> time, but only set up an outer try/catch block once.

Sorry, I misunderstood your posting...
Yes you are right. Each time you have to check the return value.

But "Kims" (and also your) point was: "try-catch is faster than checking
the return value"

And this is NOT the case.

Two assembler lines for checking the return value is at least not slower
than setting up the exception handling...

>> No guess which is faster?



If no error occur, then both methods will need almost the same time.

But if an error occurs, then the try-catch-method will consume MORE time
than checking for the return value!

Maybe your source-code looks better, but it will be slower...


--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/useritems/leakfinder.asp