Bugzilla – Full Text Bug Listing
| Summary: | Contribution of Eclipse Profiler | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Konstantin Scheglov <Konstantin.Scheglov> | ||||
| Component: | TPTP | Assignee: | Sri Doddapaneni <srinivas.p.doddapaneni> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | akiezun, ashishp, chris, darin.eclipse, ed.burnette, erich_gamma, guru.nagarajan, mauromol, max.gilead, paulslau, sluiman, tyler.thessin | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | housecleaned460 closed460 | ||||||
| Attachments: |
|
||||||
|
Description
Konstantin Scheglov
I can not upload archive, I receive following error:
INSERT INTO attachments (bug_id, filename, description, mimetype, ispatch,
submitter_id, thedata)
VALUES (53149, 'profiler_only_sources.zip ', 'Eclipse Profiler
sources', 'application/octet-stream', 0, 870, 'PK
Full archive with project can be downloaded here:
http://prdownloads.sourceforge.net/eclipsecolorer/ru.nlmk.eclipse.plugins.profiler.zip?download
Requires Eclipse 3.0 (tested with Build id: 200402250800) and VS 6.0 to build
native part. Requires classpath variable ECLIPSE30_HOME to be defined.
This is a great profiler and would be a good addition to the Eclipse Platform. It has several modes of operation, some of which are much faster and more accurate than standard java profiling hooks. In addition to the CPU profiling I've used earlier versions of the heap profiling code that can help find where all the memory is going in the program being tested. Much more information on this profiler is available on Konstantin's web site (http://eclipsecolorer.sourceforge.net/index_profiler.html) and in the eclipse newsgroups. (I'm not a developer on it, just a happy user. -Ed) Thank you for the proposed contribution. This will take some time to investigate. The proper home for the profiler is the Eclipse Tools project. To get the ball rolling please submit a project proposal (overhead is low). For details please refer to: http://www.eclipse.org/tools/docs/index.html Ok, I've written small proposal (in WinWord format), but I don't know where to send it. Should I post it in tools-dev mailing list? Or?... Good - please send the proposal to me I will then forward it to the rest of the PMC. This is being treated as a new tools project. Closing bug report. Konstantin, did anything happen in this direction? I also think that a profiling tool should be a part of eclipse jdt (we have an editor, refactoring browser, compiler, debugger, ant builder, junit runner - i think a profiler as an important part of any development process should be included too. it's not an additonal tool any more than those other are. Stand-alone tools are just so passe and installing a separate set of plugins that so many people will want anyway is a lot of hassle for many people) - but a separate tools project could be a start. I don't know how much beaurocracy it takes to start one, though. We've discussed creation of additional tools project with Eric Gamma, but main
problem is that I am not ready to make myself responsible for profiler
development. I agree that profiler is good addition to JDT, but I don't have
free time - as you may be know, I was author of SWT Designer and sold it to
Instantiations. Now I work on Designer for them. I am a little greedy :-), so
once I have job that gives me some money (not very much however), I can not
afford to use time for free project.
But I can "present" profiler to Eclipse. Well, in reallity it is already in
such state - it is under CPL, so anyone can use it.
Main reason why I've started this enhancement is mail from Ed Burnette where
ha asks me for donating profiler to Eclipse Foundation.
---
Since this is a really excellent tool and you don't have time to work
on it any more (due no doubt to the also excellent swt-designer),
would you consider donating it to the Eclipse Foundation?
---
Yeah, I was hoping some committers or community members would step up and support/maintain this and that it would become a standard part of core/debug or jdt. Having it be a whole new project makes less sense to me but that's not my decision. BTW since this entry is marked INVALID is there a new entry for it that I could cc to? for everyone's info: NB includes a profiler now. We're getting behind here TPTP includes Tracing and Profiling Tools already - http://eclipse.org/tptp/performance/index.html. New bugs/feature requests should be filed against them. sigh I agree with comment #8 so I'm reopening it as an enhancement under JDT. As Adam says, "a profiler as an important part of any development process should be included too" In response to comment #12, TPTP is overkill if you just want to make your java desktop app go faster. Konstantin's work is easy to use and understand, and it would definitely fill a need. High quality contributions like this shouldn't just be tossed aside. I notice that I didn't update the bug report after comment #6... The goal of the tools PMC is to host active projects, during the proposal process it became clear that this isn't the case for the profiler contributions, i.e., there will be no active contributors. For this reason the proposal didn't make it beyond a draft. As Kevin has pointed there is a Java profiler in TPTP. I suggest to create a bug report against TPTP which provides specific and constructive feedback (more specific than comment #13 and comment #14) on why the TPTP Java profiler isn't sufficient. Constructive feedback is always a good way to get things changing... Marking WONTFIX as profiling is outside the scope platform/JDT debug. Please file profiler related bugs/enhancement requests against TPTP (see comment #15 from PMC). Ok, let's try to reopen this under TPTP; the enhancement request would be to make this profiler available under the TPTP project either as a seperate option or to use this technology in the existing TPTP profiler. The main benefits of this contribution are increased speed of profiled code over conventional techniques, memory profiling, and an easy to use interface that requires little or no setup or learning curve. I am adding Harm Sluiman to cc list. Can someone forward me the details of what is proposed. We are always interested in improving what we do. The current profiler is targeted at a different type of use case that this proposal likely targets. The reason we have not added "lighter" use cases is lack of contribution. Chris Laffra also has some interesting tooling but we have not been able to lock in resource to maintain such feature work. We have a keen interest in getting to leverage JVMTI which implies we need to leverage BCI, but this is currentyl unstaffed as well. We do have some BCI based technology in TPTP for "probe" injection. We are also considering having a side area for interesting extensions and tools for TPTP. I suspect the views in TPTP may be reusable for this data collector, but let's have a look. Shall I just look at sourceforge link, or is there actually a summary proposal floating around? I gave TPTP a try. And had to give up pretty quickly after I found out that: 1. I have to listen to a 10 minute webcast to learn just how to install it! 2. Once I try installing it, it's 10+ steps (setting env vars, running scripts, etc). Will stay lurking at the website until that procedure is (like with other tools): 1. download a zip/installer 2. install 3. run Can we do something so that Eclipse SDK developers use TPTP. Once that happens, I'm sure lots of ideas on how to simplify things will come up. Currently, it does feel like an overkill (I just wanted to collect a bunch of perf stats). Agree we comment 14. Sorry about this not-super-constructive report. The original submission from Konstantin was a breeze to install and use. Simple things must be simple to do - complex things should be possible to do. This is actually good feedback. At the base TPTP is a platform. TPTP and Hyades before it included profiling capabilites to deal with distributed applications, and we left places in the structure that could be extended by end user products. Our original example tools were not intended to be the final thing, nor where our initial data collectors. We have since learned that even as a platform we need to provide exemplary tools and not just samples. We have alos found that the Eclipse community itself is keen to use TPTP as an Eclipse profiler. We have been listening to that feedback and while still improving things for the downstream products that like TPTP for remote and distributed tracing, we have been working at the seveal issues of being a good J2SE profiler. On thing we have introduced in the current developement stream is the install experience you desire. Install the plugins and it works. We continue to have the agent controller for distributed profiling as well as extended scalability of local profiling. This is only the first step however, and we plan to focus on the compressed/binary/agregated data collection in the 4.2 release. We have also adopted some of the Eclipse targeted tooling into TPTP such as XRay and intend to mine this tool to extend and improve TPTP. So in 4.1 we have addressed some of the problems, but not all and it is still too slow and heavy. We are addressing that next within the limited resources we have. Thanks Harm. I'll give it a try once 4.1 is out. It is always a *very* good idea to build at least 2 concrete tools and generalize to a platform then, rather that speculate requirements, try to start general and only then try to build examples. It may not always be possible but is always a must to try. Adam may have stopped sighing, but I haven't. This has has all the earmarks of a turf war between TPTP and JDT - bad for Eclipse and bad for its users. TPTP is clearly more research-oriented, aimed at distributed profiling and seems unlikely to produce a simple, practical tool for Java application profiling in the near term. If JDT could use Konstantin's contribution to put together a practical profiler that could be used on Eclipse-based applications, why not let them go ahead and do it? Bob/Adam, as I mentioned, 4.1 is a step but still not all that is needed to be a first class J2SE profiler. Nothing to hide here. This is not a research project and is extended and well used in the domain it was intended for. It is also providing successful function to other usres. Taking on Konstantin's contribution is something I would like to pursue, but our simple issue is that code needs to supported and maintained regardless where is is hosted. If we can arrange for some community support we can make more and faster progress. We had a similar problem taking on XRay but eventually Chris got support for him to work on maintaining in TPTP so we made the move, and are making plans to integrate the function, and in the meantime you and I can make good use of it as it stands. This is more a question of the focus of the project resources, whihc is governed by the contributing organizations. Like other people I believe lack of profiler is currently one of last few missing key features of Eclipse. I'm sure many users would be willing to contribute to the profiler once it's made part of Eclipse. Isn't is a bit of a chicken-egg problem? Users don't contribute to external profiler project because it's quite possible it will be left out of Eclipse at all but would be willing to work on it once it's guaranteed it will be actually included in their preferred IDE. On the other hand, Foundation says it won't be included unless it's being actively worked upon, and it's not because it's not part of Eclipse... With in Eclipse TPTP project, we have been working on a major upgrade of our profiling tool which will support JVMTI, Java 5 features, byte code istrumentation and new GUI etc. Tech preview of this tool will be available in June (as part of TPTP 4.2. This is a major focus area for the project. This integrates seamlessly into JDT. If anyone is interested and willing to contribute, you are welcome to take part in those discussions through tptp-platform-dev@eclipse.org mailing list. (In reply to comment #26) Yes, this is a great new piece of work and focused on the future of data collection in Java 5 and beyond. Doing sampling and well aggregated and/or filtered collection is also something that will be improved as we do this. The part we need contribution on as well is the ui and persistence part of the tooling. Created attachment 39170 [details]
Eclipse TPTP Java profiling
I have added a poster that the TPTP team did for EclipseCon '06, it provides an overview of what is available and what is coming in the upcoming releases.
Adding to earlier comments, apart from the profiling capabilities and profiling Java applications - TPTP java profiling integrates with Eclipse WebTools Project(WTP).
Question - does the TPTP profiler have anything to do with Konstantin's contribution? Does it compare favorably in usability and speed? I'm just wondering why this entry is being kept open and commented on if the contribution was not accepted for whatever reason. This is kept open for now while we are working on developing a roadmap for TPTP profiler; expect to complete in Q3 this year. We are looking at Konstantin's and Chris Lafra's works for ideas and possibly code reuse. I just tried to install TPTP on linux. I gave up after half an hour of chasing and installing all requirements. Eclipse Modelling framework, Agent Controller, etc. I'm sorry, but this is still a total overkill to install a profiler. It should be a 1 click installation and be done. It's unreasonable to expect people to download all requirements one by one. (In reply to comment #31) > I'm sorry, but this is still a total overkill to install a profiler. It should > be a 1 click installation and be done. It's unreasonable to expect people to > download all requirements one by one. Adam - Check out defect #159331 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=159331). I felt your pain for a few years and decided to redesign the download experience for TPTP. Hopefully I have covered your wound with the All in One driver on the main page. If you have any suggestions for improvements on my proposal please be vocal - I have tough skin ;) Adam, We do not want our users to under go this pain, We are aware of the issues and are addressing this. Simple download and usage is what we are working on. Even if you can get the TPTP Java profiler installed and working, it's orders of magnitude slower than profilers like YourKit and even Konstantin's profiler that he tried to donate here. At least in my experience with the Callisto version. Proponents of another popular Java IDE are making a lot of hay over their profiler that works, their simple but functional web tools, and their GUI builder. Our current profiler is a well used and good profiler for the use cases it was originally created for. However, that is not what the majority of Eclipse users want to use it for. The profiler and the overall usability has been improved over the course of the last releases, IAC was a good step for the out of the box experience and we are planning to make a big step forward in TPTP 4.4. Having said that we still have more to do and are addressing those aggressively now. Ed and others have seen our slow progress to improve, I would like you take the lead on being Pro-TPTP and help us drive the adoption of the improvements and our plan to move forward. Look for more announcements in this space for the TPTP Profiler. 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 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. 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. See http://dev.eclipse.org/newslists/news.eclipse.tptp/msg07287.html for user feedback to resolving this defect. (In reply to comment #41) > See http://dev.eclipse.org/newslists/news.eclipse.tptp/msg07287.html for user > feedback to resolving this defect. Hi Paul, from that discussion it seems that things are a bit changed and that TPTP is actually dead (see http://www.eclipse.org/tptp/home/project_info/devplans/EclipseTPTPProjectPlan2010.htm). So, can now the contribution of a Java profiler for Eclipse be reconsidered? Mauro. (In reply to comment #42) > (In reply to comment #41) > > See http://dev.eclipse.org/newslists/news.eclipse.tptp/msg07287.html for user > > feedback to resolving this defect. > > Hi Paul, > from that discussion it seems that things are a bit changed and that TPTP is > actually dead (see > http://www.eclipse.org/tptp/home/project_info/devplans/EclipseTPTPProjectPlan2010.htm). > > So, can now the contribution of a Java profiler for Eclipse be reconsidered? > > Mauro. Hi Mauro, I would suggest that you pursue this contribution directly with the Eclipse Platform Team since TPTP is in the position to assist. Paul |