RE: feedback on gprofng

[<mikedunlavey44@gmail.com>]

Thanks for responding, Ruud.
Your profiler does things, in my opinion, correctly. It samples the stack at
the line-of-code or instruction level, on wall-clock time.
My only suggestion is an output option. Let the user see a small number,
randomly chosen, of such stacks in raw form.
Here's an example:
https://softwareengineering.stackexchange.com/a/302345/2429

-----Original Message-----
From: Ruud van der Pas <ruud.vanderpas@oracle.com> 
Sent: Monday, March 27, 2023 15:04
To: mikedunlavey44@gmail.com
Cc: binutils@sourceware.org
Subject: Re: feedback on gprofng

Hi Mike,

Thanks for your email and suggestion.

> I suggest you have another output from gprofng:

We actually use sampling. It is the cornerstone of our approach.

> (I assume the sampling is on wall-clock time, so it has visibility 
> into
> I/O.)

Yes, we do and indeed have visibility into I/O.

We actually just heard of a use case where gprofng shows that the
(formatted) I/O is the sequential bottleneck in a multithreaded application.

We record call stacks, also for individual threads, using sampling.

The user can control the sampling granularity, either symbolically (e.g.
"high", or "low"), or through a sampling rate.

There are also filters to select call stacks, a window in time, threads,
etc.

We also just released a GUI that, among other things, has a timeline where
we show color coded call stacks. Each function we see gets assigned a color
and we show these call stacks as a function of time. This is also done for
the threads in a multithreaded application.

In this timeline, it is really easy to identify gaps in the execution.
You literally see them and by inspecting the call stacks, you can find out
where the execution was when it happened.

Kind regards, Ruud

> 
> 
> 
> Let the user choose a small number N, like 10 or 20, and then select N 
> stacks at random (with source code line info) and display them, in a 
> tree or in raw form. The point is - any performance problem consists 
> of activity that isn't necessary, and if it accounts for fraction F of 
> time, then it will show up on NF samples. High precision of 
> measurement is not necessary, but precision of insight is.
> 
> 
> 
> If there are multiple threads, let each sample be from all running 
> threads at the same time, so the user can see which threads are 
> waiting for which other threads at the point in time.
> 
> 
> 
> Let me know if this makes sense, or maybe you've already done it.
> 
> 
> 
> Thanks,
> 
> Mike Dunlavey
> 
> 
> 
> P.S. I've been advocating this for years on StackOverflow. People 
> who've tried it agree that it works. I've also got a YouTube video about
it.
> 
> 
>