Re: [Fwd: [Bug c++/14563] octave built under Cygwin very slow]

[Paul Thomas]

John,

Thanks for researching the logs for us.  I'll take a look at the 2.1.39, 
or earlier, source this weekend.

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 is

tree_simple_for_command => do_for_loop_once => quit_loop_now => OCTAVE_QUIT

Thus in the profiling tests, OCTAVE_QUIT was getting called 1 million times.

Wolfgang, who is in charge of the gcc bug database, wrote me the following:

"SJLJ stands for "setjmp/longjmp". I'm not an expert in this field 
(as I know virtually nothing about the gcc interiors anyway, I'm 
just the bug database dude), but here's the idea: when you call 
a function that may or may not throw an exception, and the calling 
function needs to run destructors of local objects in case an exception 
is thrown, you need to put down the address of the cleanup code somewhere. 
One way to do this is to set this address via setjmp, and throwing an 
exception then transfers control to this place via longjmp. This is expensive 
since you have to call setjmp every time a cleanup is necessary. 

The other possibility is to use lookup tables that the compiler generates 
statically, so this is cheap at run-time, but incurs some code overhead. If 
you generate an exception, you have to somehow look up where to transfer 
execution. Don't ask me how exactly this works, but it is to my best 
knowledge how dwarf2 exception unwinding works. Corrections on this topic 
my more knowledgable people are certainly welcome."


gcc-3.2 uses dwarf2 and gcc-3.3 uses SJLJ.  It is interesting that it 
is  _Unwind_SjLj_Register which is coming up as a time consumer in the 
slow build.

Regards

Paul T


John W. Eaton wrote:

> On 25-Mar-2004, Paul Thomas <address@hidden> wrote:
>
> | (i) To try to build octave with -fno-exceptions.  Ben Diedrich tried 
> | this but the build did not get past quit.cc.
>
> I don't think it would be easy to do that.  Octave code now assumes
> that exception handling works.  When we made the change to use
> exceptions to handle the return to the command loop after interrupts,
> we decided that it would not be worth the effort of trying to maintain
> additional code to support systems that don't do exceptions properly.
>
> | (ii) To build and compare octave-before-exceptions with the two 
> | different gcc's.  Does anybody know what version number we should be 
> | looking at?
>
> According to libcruft/ChangeLog, the code for handling exceptions with
> interrupts was added around 2002-11-07 (you could check the mailing
> list archives around that time to confirm as I think there was some
> discussion about it).  According to the src/ChangeLog file, the
> version was changed to 2.1.39 on 2002-11-01 and 2.1.40 on 2002-11-20,
> so you proably want 2.1.39 or earlier to get a version that doesn't
> use exception handling very extensively.
>
> If you think it might be exception handling, then you might also look
> at the uses of the macros related to exception handling that are
> defined in libcruft/misc/quit.h and see if they now appear in places
> that would be executed by code that demonstrates the slowdown.
>
> jwe
>
>
>