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

[Paul Kienzle]

Octave's signal handlers set a flag saying that octave should quit.  The
OCTAVE_QUIT  macro tests this flag and throws an exception.  For your
needs you don't need to handle Ctrl-C, so skip it:

        #define OCTAVE_QUIT do {} while(0)

We don't want to have to modify external libraries to include 
OCTAVE_QUIT
so instead we  do setjmp around the external code and throw an exception
back to octave if the longjmp is called.  This is buried in macros:

        BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE
        call function
        END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE

You should be able to skip these as well:

        #define BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1 do {} while(0)
        #define BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2 do {} while(0)
        #define END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE do {} while(0)

You will need to modify liboctave/misc/quit.cc so that throw is not 
used.

The F77_XFCN in libcruft/misc/f77-fcn.h does something similar in 
addition
to calling the code.  Replace it with something like:

        #define F77_XFCN(f,F,args) do { F77_FUNC(F,F) args; } while (0)

When fortran code calls back to octave, the exceptions must be 
converted into
longjmp.  This is done using:

        BEGIN_INTERRUPT_WITH_EXCEPTIONS;
        octave code;
        END_INTERRUPT_WITH_EXCEPTIONS;

These macros can be ignored for your purposes:

        #define BEGIN_INTERRUPT_WITH_EXCEPTIONS do {} while (0)
        #define END_INTERRUPT_WITH_EXCEPTIONS do {} while (0)

The only other place where I see try/catch code is in src/toplev.cc.  
This
will also have to be modified to eliminate exceptions.

I have no idea whether these changes will actually compile or not, but
assuming they do, you can compare the speed of 3.3 and 3.2 compilers
using them.  Do it without profiling so we can see what the real cost of
safe Ctrl-C is.

Paul Kienzle
address@hidden

On Mar 26, 2004, at 12:43 PM, Paul Thomas wrote:

> After I followed up John's suggestion of looking through the list  
> just after the release of 2.139, I realise that I understand nothing 
> about signal and error handling; this will have been apparent from my 
> two last messages!  I have a weekend of contemplation of such matters 
> in front of me.....
>
> Paul T
>
> Paul K, I think your suggestion of masking out the sjlj calls is a 
> good one - I just have to figure out how to go about it.
>
> > 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.
> >
> > > 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