Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "User:Alexander.n.alexeev.intel.com"
(→Our expectation from survey) |
|||
| Line 11: | Line 11: | ||
If brief, we want to change profiler and support with feedback for product. :) | If brief, we want to change profiler and support with feedback for product. :) | ||
| − | + | TPTP Profiler is universal tool which provides broad range of functionality for applications tuning (execution, heap, threading). But as other universal tools it suffers from difficulties with solving specific narrow tasks. General set of them should be almost unlimited and we aren't going to develop solution for all. In this area our goal is to define limited set of such task in collaboration with Lead User for each participated project. If users don't see specific profiling task we can assist them in this quest, at least profiler allows investigate not only execution but also heap usage and threading. We can suppose that desired task could be something like filtering narrow set of events, specific execution model, specific requirements for data depiction (e.g. reverse call tree) or specific analytical features. When tasks will be specified and documented in Wiki we can consent on most convenient solution for their carrying out, in other words we can jointly define the sequence of action which user should do to perform the task and way how information should be presented during it. | |
| − | TPTP Profiler is universal tool which provides broad range of functionality for applications tuning (execution, heap, threading). But as | + | We hope that making TPTP valuable as tool at least in some specific appliances can increase amount of users and attracts attention to it. |
| − | We hope that making TPTP valuable as tool at least in some specific appliances can increase amount of users and attracts attention. | + | |
Search for helpful project specific usage scenarios and defining solutions for them are only part of our expectations. | Search for helpful project specific usage scenarios and defining solutions for them are only part of our expectations. | ||
| Line 19: | Line 18: | ||
Also we want Lead Users bit by bit integrates TPTP Profiler in projects development process. At beginning it can cause complications but than all integration issues will be resolved we can research process with continues profiling during development, concretize role of each type of profiling and put it in certain development phase. | Also we want Lead Users bit by bit integrates TPTP Profiler in projects development process. At beginning it can cause complications but than all integration issues will be resolved we can research process with continues profiling during development, concretize role of each type of profiling and put it in certain development phase. | ||
| − | Of course starting point for participation in survey is downloading of "allinone" bundle and trying profiler but it is crucial for achieving gaols of survey to put TPTP in every day development, even periodic usage of new issued releases hardly can show requirements for profiler integration. | + | Of course starting point for participation in survey is downloading of "allinone" bundle and trying the profiler but it is crucial for achieving gaols of survey to put TPTP in every day development, even periodic usage of new issued releases hardly can show requirements for profiler integration. |
Brief list of expectations: | Brief list of expectations: | ||
Revision as of 12:47, 18 November 2007
Notes
Expectation
Our expectation from survey
If brief, we want to change profiler and support with feedback for product. :)
TPTP Profiler is universal tool which provides broad range of functionality for applications tuning (execution, heap, threading). But as other universal tools it suffers from difficulties with solving specific narrow tasks. General set of them should be almost unlimited and we aren't going to develop solution for all. In this area our goal is to define limited set of such task in collaboration with Lead User for each participated project. If users don't see specific profiling task we can assist them in this quest, at least profiler allows investigate not only execution but also heap usage and threading. We can suppose that desired task could be something like filtering narrow set of events, specific execution model, specific requirements for data depiction (e.g. reverse call tree) or specific analytical features. When tasks will be specified and documented in Wiki we can consent on most convenient solution for their carrying out, in other words we can jointly define the sequence of action which user should do to perform the task and way how information should be presented during it. We hope that making TPTP valuable as tool at least in some specific appliances can increase amount of users and attracts attention to it.
Search for helpful project specific usage scenarios and defining solutions for them are only part of our expectations.
Also we want Lead Users bit by bit integrates TPTP Profiler in projects development process. At beginning it can cause complications but than all integration issues will be resolved we can research process with continues profiling during development, concretize role of each type of profiling and put it in certain development phase.
Of course starting point for participation in survey is downloading of "allinone" bundle and trying the profiler but it is crucial for achieving gaols of survey to put TPTP in every day development, even periodic usage of new issued releases hardly can show requirements for profiler integration.
Brief list of expectations:
- Set of helpful project specific profiling tasks definition.
- Joint resolution about the best way for such tasks carrying out in TPTP.
- Iterative development with close collaboration for product evaluation.
- Filing Bugzillas against TPTP (errors, enhancements requests)
- Provide feedback for "getting started" materials, tutorials and documentation.