[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] cachegrind
|
On 04/24/2012 12:40 PM, Wainer dos Santos Moschetta wrote:
On 04/24/2012 12:21 PM, Daniel HB wrote:
On Tue, 2012-04-24 at 11:14 -0400, Andrew Overholt wrote:
* Daniel HB<danielhb@xxxxxxxxxx> [2012-04-24 11:06]:
On Tue, 2012-04-24 at 10:45 -0400, Andrew Overholt wrote:
I've been asked multiple times about post-mortem support for the
LinuxTools.
I personaly think that it's useful in all cases.
I agree it's very useful and would love to see us support it. It
just
wasn't part of the original workflows of a lot of the plugins we
have.
A good start would be, for example, not wiping out previous profiling
results from the view. We can "store" the last N results for the same
profiling.
Yes, this is good.
I just want to make internet justice and mention that this is Wainer
Moschetta's idea. We were discussing this thread on IBM IRC and he came
up with this argument of comparing previous profiling results. I forgot
to mention that in that email :)
Just a head's up: Oprofile plug-in has such as "save & compare"
feature implemented. It is really useful to compare runs when you have
just changed source code.
For Oprofile feature, you may take a look at
http://linorg.usp.br/eclipse/technology/linuxtools/videos/eclipse-oprofile-demo.ogg
demo video (see 1:36'' and then 2:45'').
Some plugins (most of Valgrind tools, gprof and gcov, for example) rely
on the original binary to display info in the view, such as line numbers
and function names. This means we would have to whether save a snapshot
of the profiled binary along with profile results or get all the info we
need from the binary and save it.
For opening any random profile maybe we can create a new perspective
called "Profile Viewer", which won't consider any project or workspace
setting, where you have the freedom to open up any profile data file
from the file system just for view.
I would rather see the same view used and just have some sort of
session
markings showing which data is driving the current visualization.
That can work too if we manage to make it very clear that the profile
view being displayed is not related at all with the current working C/C
++ project.
Andrew
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
