[PATCH 4 of 4] statprof: record samples by thread (RFC)

[Yuya Nishihara]

On Fri, 04 Nov 2016 21:53:43 -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1478321340 25200
> #      Fri Nov 04 21:49:00 2016 -0700
> # Node ID dab278ccedfb41d7a255c313fc426918ef27014f
> # Parent  dfd8e1f11e33fc1ba6cba429818ad0ea6e84dadc
> statprof: record samples by thread (RFC)

[...]

> I'm not terribly excited about the state of this patch. Specifically,
> I don't like changing state.samples to a list of tuples. I think
> recording samples in per-thread lists is preferable.

Perhaps samples could be {tid: [sample, ...]} dict. But we might need to
keep accumulated_time, last_start_time and seconds_per_sample() per thread,
so state might be a dict of {tid: state}. Not sure which is better and easier
to implement.

> I'm throwing
> this patch out there to see how it is received. Previously, I had
> implemented "stack based" profiling where the last thread to call
> start() was active. People didn't seem to like this because it only
> allowed measuring a single thread. This approach allows measuring
> multiple threads.

I think this approach is better than the stacked one and would work fine
for our use case, which I assume we want to get a sample of single hgweb
request/response (so there are 1 mostly-sleeping thread + 1 active thread.)

I said the "stack based" one wasn't nice because stat/stop pair isn't always
stacked. The stop() of one thread could stop the profiling started by another
thread.