hallo,
we have an application that throws a kind of c+±timeout-exception
(derived from std::exception). if the exception is thrown, we can see
with tracelogger that it takes about 100us to throw and catch the exception.
the cpu of the system is a transmeta-crusoe at about 660mhz - on a
celeron maschine it takes only about 60% the time …
the code is something like this:
try
{
throw int();
}
catch(…)
{
}
there is no nested function-call an nothing to implicity delete, there
isn’t “much stack to unwind” - but why takes is so much time ?
we use gcc 3.3.5 and neutrino 6.3.1 …
another “problem”: it seems that the throwing process isn’t preempted by
higher-priority processes while the exception is thrown/catched ?
i think we do something completly wrong - but i have no idea what ?!?
thanks
stefan
Stefan Zell wrote:
hallo,
we have an application that throws a kind of c+±timeout-exception
(derived from std::exception). if the exception is thrown, we can see
with tracelogger that it takes about 100us to throw and catch the
exception.
the cpu of the system is a transmeta-crusoe at about 660mhz - on a
celeron maschine it takes only about 60% the time …
That’s normal. GCC is designed to handle the no-exceptions case
with zero or minimal additional overhead. The price of this is slow handling
of exceptions. Exception handling involves searching tables and
working through lists of what to do about possible exceptions.
See this article:
http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Exception-Handling-Control.html
This discusses the issue for Ada, compiled with gcc, but some of
the discussion applies here.
another “problem”: it seems that the throwing process isn’t preempted by
higher-priority processes while the exception is thrown/catched ?
That seems unlikely. Exception handing and process scheduling
are independent.
John Nagle
Animats