Community
Participate
Working Groups
The Model loading & Saving must be performant and scale well. The entire model must not be loaded into Memory. We must support models that are larger than the amoutn of memory available on a machine.
Under investigation during the 4.3 plan cycle. A solution in 4.3 is not anticipated.
This seems to be a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=144950
The Trace Model optimization solution should address the following issues a) The model must not be an in-memory model and should scale for long running applications b) The usage that this model changes should support may include the a Database solution but must support by default a file system based persistence support. The lack of a database solution increases the Out-of-box usability and also the portability/availability of database solutions on certain platforms. c) We support two use-cases in profiling - online and offline profiling, offline profiling is one where we export data from a model and import the data for analysis on a different machine or have the agent run in the standalone mode and import the trace output. For the scenario where we support exporting from the model - the output format today is XML and this does not scale up. Additional default serialization methods like csv etc. should be provided.
I think that the fourth requirement ("Additional default serialization methods like csv etc. should be provided.") should be split into a different feature. Rather, this feature should focus on finding one serialization method that improves the current situation and other features can work on improving it even more by investigating other serialization options. To add support for more than one serialization method (especially when the serialization methods, other than CSV, haven't been identified) could make this feature so large that it would not be doable in one release. This feature should focus on getting the flat file system set up, should look into making that serialization option pluggable, and should look into setting up an automated test bucket so that regressions in performance could be caught during each iteration's test pass. There is no such performance bucket today.
Description document updated to reflect the new requirements posted in comment #3.
Moving untargetted enhancements to Future target.
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.
