Bugzilla – Full Text Bug Listing
| Summary: | [Workbench] UI is now very sluggish | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alvin Thompson <alvin> |
| Component: | UI | Assignee: | Billy Biggs <billy.biggs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | douglas.pollock, eclipse, ed.burnette, john.arthorne, ovidr |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Alvin Thompson
*** This bug has been marked as a duplicate of 37847 *** crap.. wrong bug. Which build of 3.0 are you using? currently, last week's integration build (gtk) i use somewhere around a 1.8GHz P4/512M. problems have been mostly around since the new look, although resizing is substantially improved. really, the 'intro' view is nice and zippy. clearly, it renders differently then the others. if you get the other views to behave like that one (and speed up overall redrawing, especially while resizing), it would go a long way... you may want to consider just not showing the contents of fast views as they redraw. since regular views do not show contents when resizing, that behavior is inconsistant, anyway. correction: you may want to consider just not showing the contents of fast views as they *resize* There are a lot of issues in here, so let's try and split this up and investigate each individually. First I'll address some of the ones that I know have bugs open already. 1. The gray blocks issue is an annoying one. See bug 34365. I find it interesting that some people see this a lot more than others (I've never seen it myself). Do you use code assist? 2. Regarding resizing and the perspective bar / tool bar, see bug 56330 and bug 56829. The major annoyances seem to be fixed now. 3. Flashing on tab switches and during perspective switch. Part of this is related to controls assuming that setRedraw() works. See bug 53791 for why this is challenging under Linux/X11. While it may sound bad, I do believe we can improve the situation even if we never get the full setRedraw() functionality. 4. There have been bugs about fast views, and also a steady stream of development and improvements, so this has been a moving target. In M8 and in the latest builds, I think they seem a lot faster here than what you're seeing. Personally, I don't think we should give up on opaque resizing of fast views just yet: maybe it's just exposing something else that's unnecessarily slow? To help approach this, would you mind posting a screenshot showing what view is a fastview, and what's under it? I think it might help to have a benchmark. Moving foward, I will open some more specific bugs. I believe we can improve the performance of perspective switching, and maybe rework it with the Linux drawing issues in mind, so I will open a bug about that. We should have a bug about the startup speed issue, or maybe we should open a new one about that. Regarding redrawing speed, let's try and have some specific cases in mind. Can you describe some situations that you can see where certain controls are just far too slow? What's the best way to track down why a particular UI slowness is occurring? Debug trace options (which ones?), Java memory profilers (recommendations?), CPU profilers (which?), System specific monitors (perfmon, filemon, ...?), etc.. I feel that I could submit much more helpful reports if I could narrow it down a little bit first. For example, it could turn out that I have a network problem or a corrupt workspace or something unique like that on my end. There are three basic types of performance evaluation -- at least, that I know of. 1.) Responsiveness. This is essentially a measure of how long the event thread is tied up handling a single user event of some kind. This can be tested using the "Patch to provide debugging information from SWT" on Bug 49524. This patch is old, and may need some tweaks to apply cleanly to the most recent SWT code. Basically, it prints a message if some event processing takes longer than 200ms. You can adjust the time depending on your machines performance characteristics. 2.) Raw Speed. This is a measure of how fast things are going compared to how fast they could go (in the optimal world). This one is tricky to measure because you have to choose some task (say, switching perspectives) and then try to decide if it's taking a long time compared to what it could take. Profiler tools are sometimes useful in determing potential weaknesses, but in complex applications like Eclipse they can also be confusing to use. 3.) Perceived Performance. This is a measure of how fast things are going compared to the type of work flow taking place. For example, it is reasonable for a perspective switch to take a while (infrequent event), but if typing a character takes 5ms, that's far too much. This also ties in with repainting issues, which can make something seem a lot slower (as you can watch intermediary, ugly steps). This is the hardest to measure, and really just takes people complaining that "task X is slow enough to both me". Once the general problem area is known, you can use profilers. The profilers that the UI team is currently using are YourKit and OptimizeIt. They work reasonably well for memory and CPU profiling, respectively. If you have a specific task, then you can use a similar mechanism to the patch (currentTimeMillis and printlns) to get some idea of how long it is taking; this can be helpful for cross-platform comparisons. I posted bug 58738 regarding slow perspective switching on Linux-GTK and describing some of what we know about the problem already. Regarding fast views, see bug 57143. See also bug 58174. OOps... I meant bug 56694. Alvin: One of the things you mentioned in your report was that you see a longer startup time now. I can't reproduce that behavior here. All of M7, M8, and the latest integration build take about the same time to start up on my machine. Do you just mean the time between seeing the splash screen and the window appearing, or something specific about the time between the window opening and the contents appearing? If you have some specific numbers, or information about how many projects were open (or whether they were already built?) or other specific information then that might be useful. It doesn't sound like this is a UI issue though. I have done some more research into the flashing on editor or view switch, and opened bug 59528 to track this issue. As M9 is approaching, I would like to summarize the issues we have identified from this bug report so we can close it. 1. Flash when switching editors and views This is being addressed in bug 59528 and bug 53791 and is definitely improved from M8. 2. Fast view performance There have been many performance improvements made to fastviews (bug 57143 for example). I also suspect bug 56694 hurt us here: the resizing of fast views causes the gradients to be sent again to the X server, but the big one is gone now so this should be fixed. 3. Perspective switching is slow Bug 58738 describes some of what we have learned about perspective switching on Gtk+. More work is needed here. 4. Startup time is slower While I have not been able to reproduce this problem here, I believe this will be solved from bug 56694 as we send fewer gradient images. 5. Perspective bar rendering errors Fixed from bug 56330 and bug 56829. 6. Gray blocks in the text area Fixed from bug 34365. Given that we have bugs open for all of the remaining issues, I think we can close this bug. Even though this bug isn't "fixed", I'm marking it as such since we are addressing all of the remaining issues elsewhere. I think this bug was useful because we had a lot of reproducable and specific issues which we could address individually. Alvin, if you have more cases like these please post another bug. |