[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Performance Tools Framework
|
Thank you Greg, that is good to know. I will start looking into making the plugins EFS-safe.
Presently the invocation of some analysis tools is done via Runtime.exec() calls. It should be easy enough to detect when resources aren't available locally and thus refrain from using them. However, eventually I will need to consider options for either invoking analysis tools remotely, or transferring data to the local machine for analysis.
-Wyatt
On 10/1/07, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
Wyatt,
I haven't taken a look at the performance plugins, but since you're working with external tools you should be cognizant of Eclipse Filesystem (EFS) issues. I'm just going through this exercise with CDT, so I can attest that it is much more difficult to address this in retrospect.
The main issue is that you can not assume that the workspace is physically located on the same machine that is running Eclipse. This has a few implications:
1. Any call to
IResource.getLocation() can return a null. It is better not to use this at all, but rather use IResouce.getLocationURI().
2. An IPath has traditionally been used to refer to both a resource in the workspace, and a resource in the filesystem. However this no longer holds true. IPath can still be used, but you need to be careful that you're not trying to access a resource that doesn't exist locally.
3. Any operations using java.io.File to manipulate resources directly can fail, since the resource may not exist locally.
The rule of thumb here is:
a) Use IResource methods to manipulate resources. IResource should already deal with EFS issues.
b) When IResource is not sufficient, use the URI to lookup the IFileStore and/or IFileInfo. These interfaces have additional file operations that will allow you to do everything you need.
c) Be extra careful when dealing with passing resources and/or paths to/from external tools. If the filesystem is not local, then the tool should probably not be local either, since if it needs to refer to a file, the file may not exist.
There are some additional EFS resources here:
Let me know if you need any further clarification.
Greg
On Sep 27, 2007, at 9:12 PM, wspear wrote:
Beth, I was wondering about the status of your selective instrumentation work. As I recall you were looking into storing within eclipse itself user specified information on what routines should and shouldn't be selected for instrumentation, as opposed to on the file system, and on marking elements selected or excluded for instrumentation within the editor.
The difficulty I've had with my initial approach to this has been getting the different components to talk to each other. The selection takes place in the editor/workspace but I haven't found a good 'Eclipse-y' way to make information associated with the editor easily accessible by the launch or build systems, which are what ultimately put the selective instrumentation data to use. Internally stored selective instrumentation data will be useful, in particular, for generating selective instrumentation files for multiple tools from a single source.
This is becoming more relevant as the latest batch of updates to the performance plugins (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=168292) offers support for multiple user-defined performance tools. This includes tools like psrun that take the program to be analyzed as an argument and tools like TAU that recompile with instrumentation. The next release should be generalized enough to support all the performance tools I've been able to get my hands on to test. There is also some rudimentary support for tool workflow, which I hope to expand on soon.
I still need to work on developing extension points for the plugins. Right now they read an arbitrary XML file for tool definitions. These high-level tool definitions work for some tools while others (TAU included) have more complicated interfaces that may require tool-specific extensions.
Regards,
Wyatt
On 8/18/07, Beth Tibbitts <
tibbitts@xxxxxxxxxx> wrote:
We are working on generalizing some performance tools integration work with
PTP and Eclipse.
So that we can reuse the "Eclipse plumbing" that plug-in work for TAU (U.
Oregon), TuningFork (IBM) and PAPI etc. (U. Tenn.) are developing,
We are working on providing the generic work within a framework such that
less work has to be done for each new tool integration.
For an outline of the 5 basic points of integration that seem to be most
readily generalized,
see the wiki at:
http://wiki.eclipse.org/PTP/designs/perf_tools_framework
But, basically these five points are:
1. Instrumentation
2. Build, which may or may not be transparent to user
3. Launch with instrumentation
4. Management of profile/trace data
5. Visualization / Analysis of profile/trace data
To start with I am prototyping some eclipse tools to assist users in adding
performance
instrumentation lines to source code. So far about 90% of the code is in a
generic plug-in to which
the user/client writes an extension plug-in that uses that and requires
very little code to implement.
Next I will work on instrumentation that doesn't modify the user's source
code at all,
a "transparent" instrumentation that e.g. instruments a copy of the source
code then builds.
Others may be working on other areas of the framework. Stay tuned for more
details.
As we firm up the details we will expand the information on the wiki page
listed above.
I just wanted to make sure that information made it to the ptp-dev list to
inform others.
...Beth
Beth Tibbitts (859) 243-4981 (TL 545-4981)
High Productivity Tools / Parallel Tools http://eclipse.org/ptp
IBM T.J.Watson Research Center
Mailing Address: IBM Corp., 455 Park Place, Lexington, KY 40511
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
