Re: [PATCH v2] Speed up next/step while debugging multithreaded programs on AIX.

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2026-09-10 09:14, Ulrich Weigand wrote:
> Aditya Vidyadhar Kamath <akamath996@gmail.com> wrote:
> 
> +      /* Attempt to sync_threadlists() only when debugging object
> files
> +	 and not core files since the list of threads never changes
> for
> +	 core files.  Even for live inferiors, skip the sync when the
> +	 thread count matches the previous stop.  */
> 
> This last part seems racy to me.  In principle, it is possible
> that one thread terminated and simultaneously one new thread was
> created, since the last time we stopped.  In this case, the thread
> count would be the same, but the thread list still incorrect.
> 
> Given the other test for single-stepping, is this particular
> check even still resulting in a noticeable performance
> difference?

I would suggest making a patch with just the get_signaled_thread batch
change first, since that one looks fairly safe and low hanging fruit.
Then, measure again and then look for the next optimization.

I would suggest using the "scoped_time_it" class to measure the
execution time of various functions and scopes.  This object measures
the time spent between its construction and destruction.  On
destruction, it prints a line like:

  Time for "DWARF indexing worker": wall 0.195, user 0.130, sys 0.033, user+sys 0.163, 83.6 % CPU

Include that information in your future commit messages (the before and
after).  That will give us an accurate picture of where time is spent,
and how much each optimization helps.

Just sprinkle it like this:

  {
    scoped_time_it time_it ("doing something");

    ...
  }

And then enable it with:

  (gdb) maintenance set per-command time on

Simon