| From | Namhyung Kim <> | Date | Fri, 26 Dec 2014 11:10:33 +0900 | Subject | Re: [PATCH 13/37] perf tools: Use thread__comm_time() when adding hist entries |
| |
On Fri, Dec 26, 2014 at 7:53 AM, Jiri Olsa <jolsa@redhat.com> wrote: > On Wed, Dec 24, 2014 at 04:15:09PM +0900, Namhyung Kim wrote: > > SNIP > >> >> he = __hists__add_entry(hists, &al, NULL, >> - NULL, NULL, 1, 1, 0, true); >> + NULL, NULL, 1, 1, 0, -1, true); >> if (he == NULL) >> goto out; >> >> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c >> index 9314286ed25c..d322264bac22 100644 >> --- a/tools/perf/util/hist.c >> +++ b/tools/perf/util/hist.c >> @@ -451,11 +451,11 @@ struct hist_entry *__hists__add_entry(struct hists *hists, >> struct branch_info *bi, >> struct mem_info *mi, >> u64 period, u64 weight, u64 transaction, >> - bool sample_self) >> + u64 timestamp, bool sample_self) >> { >> struct hist_entry entry = { >> .thread = al->thread, >> - .comm = thread__comm(al->thread), >> + .comm = thread__comm_time(al->thread, timestamp), > > with thread object having multiple comm entries, could this hurt > the single threaded performance?
Probably. But in my test, the single threaded performance on a single data file is slightly better or almost same. I didn't investigate it yet where the performance gain comes, but anyway, I think this has almost no effect on the performance since most thread will have just one or two comms I guess.
And JFYI, the single threaded performance on a multi-file data is better (I tested same data using 'perf data split' command and no --multi-thread option to perf report) as IMHO it doesn't need to use the ordered event queue layer.
> > The thread__comm_time function iterates comm_list each time, > maybe you could add some 'last_comm found check' logic in it?
I think it can be easily added later if it really affects the performance.
Thanks, Namhyung
|