Diff for "PerformanceProfilingRFC"

TableOfContents([2])

About this document

This is an official Request for Comment (RFC) for PerformanceProfiling.

For details on RFCs in general, check out the [http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments Wikipedia Entry: Request for Comments (RFCs)]

Status

02/06/07 Not yet completely written

How to Comment

To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: ["/Comment"].

Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

Proposal

Between former releases the performance of Cytoscape was an issue when a different graphical engine was implemented. To avoid problems like that a structured way of preferably internal automated profiling tools should be available to both (plugin)developers and testers Two distinct reasons for profiling:

1: Guarantee that performance and memory footprint won't deteriorate resp. increase in newer versions

2: Detecting design problems and thereby improving performance and/or memory usage

This leads to two distinct ways of implementing performance profiling

1: Provide an Ant test-gui like task that runs former (which?) version of cytoscape versus the current version and guarantees that certain User Scenarios are performed at least as fast, and with at least the same memory footprint, and below certain pre-determined reasonable tresholds. As a starting point the current implementation of ScooterMorris can be used, extended with some memory analysis.

2:Assign a profiling role to one or two developers. Using a standard open source profiling tool(eclipse TPTP, EJP, Profile4J) they profile Cytoscape performance on a regular (weekly) basis keeping an eye on extensive object creation, long delay in methods etc. Developers concerned will be notified.

Biological Questions / Use Cases

* Load large network

* Apply spring embedded layout

* Save/Load session

General Notes

Requirements

Deferred Items

Open Issues

Backward Compatibility

References

Implementation Plan

1: To maintain application efficiency

• Create a separate directory "/profiling" with own build.xml and testclasses ProfileTest.java CompareProfilesTest.java and file ProfileTest.xml in both the Cytoscape trunk and last release.

• ProfileTest.java is a set of Gui Use Cases that are performed in the same way as the test-swing target. The class also extends the Profiler class from ScooterMorris (extended with memory size calculation) and outputs time spent in tests and current memory as values to a file

• The build contains a sequential set of three ant tasks; properties are read from a properties file and these define the paths to the former and current versions

  • First task runs ProfileTest.java within current (== trunk) version of Cytoscape

  • Second task runs ProfileTest.java in the former release and appends profiling values to text file

  • Third task runs CompareProfilesTest.java that reads the textfile, compares values and outputs them in the usual way to junit.html; warnings or errors occur when values indicate decrease of performance

• Run this task from the current trunk cytoscape test. Subsequent release follow the same procedure

• Care must be taken that the ProfileTest.java performes the same type of task but written/ performed in the local specific code

2: To detect design problems

• Choose type of profiling tool?

Comments

PageComment2