Community
Participate
Working Groups
Currently, execution time analysis profiling type, allows for collecting method entry/exit data in two ways: statistical and full graph mode. Statistical mode collapses all method entry/exit events into method level statistics data. Full graph mode saves all the method entry/exit events as they are in the model. The 3rd mode, would be an aggregating mode, would collapse the method entry/exit events along unique call chains and stored in the trace model. Support should be added to hyades using extension points, so that this new collection/processing mode can be built easily on top of hyades.
Mani, 3.3 realease is already closed The closest releases to include new requests are 4.1 and 4.2 We can still get this into the 4.1 plan if you think this is something that should be done asap.Can you please add a usecase scenario to explain why is this new collection mode required and how it will be used. What are the implications of using this mode ( performance improvements, nice to have feature, etc )
Upadate version and target to include this feature into the 4.1 bucket, although this feature will not be reviewed by the 4.1 requirements group until we have a usecase explaining the usage of the function.
I can think of couple of different use cases for this collection mode and extension point. Use case 1: Workbench side aggregation of execution profile information This applies to both launch as well as import use cases. Currently, building aggregated call chains requires the entire trace data be loaded into the model before aggregation can begin. If all one is interested in aggregated data, then this is a waste of time and resource. In the aggregated collection mode, the trace model will be populated using aggregated method invocations. This mode would prevent the views that depend on the full trace (e-g sequence diagram and execution flow). Aggregated collection mode would properly fill the model for the statistical views. Use case 2: An aggregating agent (aggregations done on the agent/collector side) sends out aggregated method invocation fragments which are loaded into the trace model directly. While no explicit workbench side extensions are required to support this, the collection mode would help views analyze the data correctly.
move to TPTP for psot 3.3 work
Deferring from 4.1 as per the official 4.1 enhancement plan. http://eclipse.org/tptp/home/project_info/featureplans/features.php?source=All&project=All&release=4.1&file=TPTPFeatures_4.1.xml
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
