Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads

[Tom Tromey <tom@tromey.com>]

>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:

Philippe> That looks like a nice startup speed improvement, will be much appreciated
Philippe> when debugging big executables at work :).

Philippe> I however do not observe much parallel CPU being used.
Philippe> What type of operations will be mostly helped by parallel threads ?

With this series, only demangling of minimal symbols is parallelized.
This does not dominate startup except in unusual situations, maybe a
very large C++ library that has no debuginfo and is unstripped.

Locally I only saw utilization of 1.5 CPUs or so -- so, not very
parallel yet.

The real point of this series is to flush out some of the lower-level
problems with having threading in gdb, so we can use it in more places.
For example, in this series, the SEGV handler stuff; but also this was
the reason for the big exception handling changes.

A better win, I think, would be to parallelize partial symbol reading in
dwarf2read.c.  This is a bit tricky... there are cross-CU references to
consider, and also the bcache seems like a point of contention.  I've
been wondering if, instead, it would make sense to change the DWARF
reader not to make partial symbols at all.

Philippe> One comment about 'maint set|show enable-threads' :
Philippe> what is the reason to have this as a maintenance command ?

I see it as a setting for gdb developers, not gdb users.  In fact, v1
didn't have this, but John wanted a way to disable threading for
debugging gdb.

Philippe> Also, maybe it would be better to have this setting being the
Philippe> maximum nr of threads to use.  In some environments (e.g.
Philippe> operational environments), one might want to limit the nr of threads
Philippe> used by GDB.

I think that most users don't know what most programs do under the hood;
nor should they need to.  I suppose in some extreme situation maybe
someone would want to do this, but disabling threading in this case
should be good enough.  Users like this should probably use gdbserver
instead though.

Philippe> Note also that I see GDB is starting some threads by default
Philippe> when guile is configured in, and 'maint set enable-threads off'
Philippe> seems to not disable this type of threading.

Guile creates threads by default.  In general gdb can't control the
threads made by either Guile or Python, because those can be made by
scripts created at runtime.

Tom