Re: [tracecompass-dev] Performance of CPU usage analyses with many threa

[rreinsberger@xxxxxxxxx]

Hello Geneviève,

Thank you for the data and explanation, that sounds good to me.
"the algorithm is not linear" - acknowledged, even my recent crude black 
box experiments were suggesting that it is not :-).

Some more info on the check box behavior FWIW:
Unselecting a thread takes even longer to produce a result than 
selecting it.
- I expanded the tree and selected the topmost thread (took the usual 
~5s to finish rendering).
- I collapsed the tree and unselected the remaining single checkbox - 
that took ~70s to complete the rendering.
- I tried the same procedure with the bottommost thread in the tree and 
it took ~15s to complete.

That's strange but maybe all checkboxes need to update their status from 
"top to bottom" every time a change happens. That would explain why it 
takes longer to unselect a thread from top than from bottom. However, it 
does not explain why unselecting seems to take at least 3 times longer 
than selecting. Anyway, mere conjecture and doesn't actually make much 
sense.


Regards,
Rudolf

Am 2019-02-21 18:43, schrieb Genevieve Bastien:
> Hi Rudolf,
>
>
> There was no benchmark for the CPU Usage analysis, so I made one that
> queries the backend. For manyThreads, it takes 2.15 minutes to query
> 10 times the tree on the left and the CPU usage for all threads. There
> was an easy performance fix, got that down to 1.5 minutes for 10x the
> full queries (so ~9s for one query of both tree and graph data). So
> the problem is definitely not the backend (the algorithm is not
> linear).
>
> After doing some more profiling according to your comments, one would
> think that if the checkboxes are not visible, they would not be
> rendered, but that is apparently not true, it is still checking the
> checked state of each box, no matter if it's visible or not. And that
> still takes forever. Somebody in the team is looking into this.
> Hopefully we'll "fix" that pretty soon.
>
>
> Thanks and don't hesitate if you notice any other such performance hit!
>
> Regards,
>
> Geneviève
>
>
> On 2019-02-21 4:36 a.m., rreinsberger@xxxxxxxxx wrote:
> > Hello Geneviève,
> >
> > I tried the same with a collapsed tree so that only the topmost check 
> > box remains. So, selecting this one implicitly selects all 1535 
> > collapsed threads. Although there is nothing apparently to render in 
> > this case (in terms of individual thread checkboxes) the result is the 
> > same as with the expanded tree view.
> >
> > However, trying to render just individual threads from this example 
> > takes between 5s to 7s on my machine (which is well aged but with an 
> > i7 core after all). That would roughly mean about 2 hours to render 
> > all 1535 threads. So, I am not that sure that it's definitely the GUI 
> > check boxes causing this run time?
> >
> > As the many-threads example I use is from the test repository do you 
> > know if there is any test protocol for this test case telling about 
> > the expected results and run time?
> >
> > Regards,
> > Rudolf
> >
> >
> >
> > Am 2019-02-18 16:44, schrieb Genevieve Bastien:
> > > Hi Rudolf,
> > >
> > > Wow, reading this bug report brings back memories... Claudette 
> > > nodes...
> > >
> > > Anyway, indeed, on the backend side, there should be no performance
> > > problems anymore, and from doing a bit of sampling after reading your
> > > mail, the performance problem you're experience comes from the
> > > frontend: The UI spends most of its time rendering checkboxes of the
> > > tree items... Because there's a lot of items in this tree, yet only a
> > > few of them are visible. I think the 'tree' widget of those views
> > > should be more lazy and display only the visible items instead of all
> > > of them. There should be a bug for that. Especially that we have more
> > > and more of that type of views with a lot of items...
> > >
> > > Thanks for bringing this up,
> > >
> > > Regards,
> > >
> > > Geneviève
> > >
> > >
> > > On 2019-02-18 8:05 a.m., rreinsberger@xxxxxxxxx wrote:
> > > > Hello,
> > > >
> > > > Evaluating the CPU usage analyses and view I used sample/test data 
> > > > from here:
> > > >
> > > > https://github.com/tracecompass/tracecompass-test-traces/tree/master/ctf/src/main/resources/many-threads
> > > >
> > > > … and from here (see file attachment in the report):
> > > >
> > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=460261
> > > >
> > > > Trying to update the CPU usage graph with all threads selected the 
> > > > analyses took a very long time (>30 min) until Trace Compass (v4.2) 
> > > > was eventually rendered unresponsive.
> > > >
> > > > It seems that in the bug report referred to above this problem (or 
> > > > at least parts of it) were addressed. However, I am not sure what 
> > > > performance and results are to be expected for this test traces. Is 
> > > > the CPU usage supposed to work and produce results with this trace 
> > > > data in TC version 4.2?
> > > >
> > > > Regards,
> > > > Rudolf
> > > > _______________________________________________
> > > > tracecompass-dev mailing list
> > > > tracecompass-dev@xxxxxxxxxxx
> > > > To change your delivery options, retrieve your password, or 
> > > > unsubscribe from this list, visit
> > > > https://www.eclipse.org/mailman/listinfo/tracecompass-dev
> > > _______________________________________________
> > > tracecompass-dev mailing list
> > > tracecompass-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or
> > > unsubscribe from this list, visit
> > > https://www.eclipse.org/mailman/listinfo/tracecompass-dev