|
From: | Paul Thomas |
Subject: | Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow] |
Date: | Fri, 26 Mar 2004 14:38:26 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 |
Paul, Excuse my ignorance, but I thought00082 00083 <http://pareto.uab.es/mcreel/OctaveClassReference/html/quit_8h.html#a2> #define OCTAVE_QUIT \
00084 do \ 00085 { \ 00086 if (octave_interrupt_state > 0) \ 00087 { \ 00088 octave_interrupt_state = -1; \ 00089 octave_throw_interrupt_exception (); \ 00090 } \ 00091 } \ 00092 while (0)00093 is doing a bit more than signal handling in the octave_throw_interrupt_exception? What does
GCC_ATTR_NORETURN <http://pareto.uab.es/mcreel/OctaveClassReference/html/config_8h.html#a174> do then? Paul T Paul Kienzle wrote:
On Mar 26, 2004, at 6:52 AM, Paul Thomas wrote:Also, thanks for the suggestion about tracking down the use of quit.h in the time consuming bits of code. I had already started that just before going on the present trip. There is at least one occurrence; from the scribbles in my journal, the chain istree_simple_for_command => do_for_loop_once => quit_loop_now => OCTAVE_QUITThus in the profiling tests, OCTAVE_QUIT was getting called 1 million times.The OCTAVE_QUIT macros are needed for signal handling. They are not yet used for error propogation as far as I know. Surely you could build a version with dummy macros for the purposes of timing? Paul Kienzle address@hidden
[Prev in Thread] | Current Thread | [Next in Thread] |