This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [python] Avoid saving signal masks for Python API.


Hi Yichun,

A year later, but ...

On 02/10/2015 06:32 PM, Pedro Alves wrote:
> On 02/05/2015 01:40 AM, Yichun Zhang (agentzh) wrote:
>> Saving the siginal mask in sigsetjmp involes the expensive
>> sigprocmask syscall while in our Python API, it is not likely
>> for the C primitives to mess up with signals. Also, value_rtti_type
>> is heavily called from within Python API, which does not mess up with
>> signals either (feel free to prove me wrong).
>>
>> This change leads to 11%+ speedup in our "lgcstat" [1] GDB python script
>> and 14%+ speedup in our "lgcpath" [2] script while Python 3.2 is used.
>>
>> Alas, even the sigsetjmp calls without signal mask saving still
>> introduce significant performance overhead (also for the surrounding
>> code). Nevertheless, this patch can serve as a good start anyway and
>> we can try further optimizations along this way in the future.
>>
>> If you have any better suggestions, please don't hesitate to drop
>> me a note.
> 
> Thanks.  Impressive the speed we can get out of this.
> 
> It seems to me this tackles things from the wrong end though.
> 
> I think we should enumerate the cases where we throw
> from a signal handler, and treat _those_ specially.
> 
> Off the top of my head, that will be when immediate_quit it set,
> the SIGFPE handler, though that seems to be broken anyway,
> and when calling into the demangler and catch_demangler_crashes
> is set (though that uses explicit sigsetjmp instead of TRY_CATCH),
> and maybe the various SIGINT handlers.
> 
> We'll need to contain these for C++ too.
> 
> I'd be curious if you already see the speedup with this series
> 
>  https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html
> 
> given that that switches TRY/CATCH to use C++ exceptions / Dwarf
> unwinding instead of sigsetjmp/longjmp.

As you've seen in the other email, this is now complete.
gdb now uses setjmp/longmp for all TRY/CATCH blocks.  In addition, 
current master also uses C++ exceptions / Dwarf unwinding in C++
mode.  I'm curious on whether you could try your scripts again 
with current master.

I'm hoping for an extra speed up in C++ mode.  There's still a
little bit of overhead in TRY/CATCH to maintain the cleanups chain,
but should be less than in C.  If you could try C++ mode, it'd
be much appreciated.  You just need to configure gdb
with --enable-build-with-cxx for that (assuming GNU/Linux).

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]