Re: [PATCH] Don't use the mutex for each symbol_set_names call

[Tom Tromey <tom at tromey dot com>]

>>>>> "Christian" == Christian Biesinger via gdb-patches <gdb-patches@sourceware.org> writes:

Christian> It speeds up "attach to Chrome's content_shell binary" from 44 sec -> 30
Christian> sec (32%) (compared to GDB trunk), or from 37 sec compared to this
Christian> patchset before this patch.

Nice.

Christian> +	  [&] (minimal_symbol *first, minimal_symbol* last) {
Christian> +	    std::lock_guard<std::mutex> guard (demangled_mutex);
Christian> +	    for (; first < last; ++first) {
Christian> +	      symbol_set_names (first, first->name,
Christian> +		  strlen (first->name), 0,
Christian> +		  m_objfile->per_bfd);
Christian> +	    }
Christian> +	  });

IIUC the idea is to separate the demangling from updating the
demangled_names_hash.

A couple of thoughts on that...

Christian> +          *slot
Christian> +            = ((struct demangled_name_entry *)
Christian> +      	 obstack_alloc (&per_bfd->storage_obstack,
Christian> +      			offsetof (struct demangled_name_entry, demangled)
Christian> +      			+ len + demangled_len + 2));
Christian> +          mangled_ptr = &((*slot)->demangled[demangled_len + 1]);
Christian> +          strcpy (mangled_ptr, linkage_name_copy);
Christian> +          (*slot)->mangled = mangled_ptr;

There's no deep reason that these things have to be stored on the
per-BFD obstack -- and requiring this means an extra copy.  Instead we
could change the hash table to use ordinary heap allocation, and I think
this would be more efficient when demangling in worker threads, because
we could just reuse the existing allocation.

Also, it seems fine to serialize the calls to symbol_set_names.  There's
no need for a lock at all, then.

One idea I had was to parallelize build_minimal_symbol_hash_tables as
well: when possible, have it run two threads, and create the hash tables
in parallel.  Adding a third thread here to update the
demangled_names_hash might help too?  Maybe this approach would
eliminate the need for your "Compute msymbol hash codes in parallel"
patch ... the issue there being that it makes the minsyms larger.
(Another way to handle that would be to keep the hashes in a local array
of some kind that is discarded once the hash tables are updated.)

Tom