This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [python] Avoid saving signal masks for Python API.
- From: Pedro Alves <palves at redhat dot com>
- To: "Yichun Zhang (agentzh)" <agentzh at gmail dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 12 Apr 2016 18:42:18 +0100
- Subject: Re: [PATCH] [python] Avoid saving signal masks for Python API.
- Authentication-results: sourceware.org; auth=none
- References: <1423100402-19533-1-git-send-email-agentzh at gmail dot com> <54DA4EB7 dot 8020207 at redhat dot com>
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