Community
Participate
Working Groups
Created attachment 100015 [details] screen cap I20080510-2000 1. Show synchronize view 2. Incoming mode 3. Show change sets 4. Synchronize workspace 5. Wait After a while you get a couple of "change sets" called something like 'Error: no label provider blablabla'. 6. Set focus to another app 7. move other app around Is: Synchronize view needs a lot of CPU and a couple of secs to refresh. See video. Should: Be fast, like for other views. Even without the missing label providers it is still pretty slow.
Created attachment 100449 [details] Sync view not entirely refreshed When I was playing with Sync view I didn't observe the situation when all CPU gets eaten. But let me dobule check it on a different machine. I did notice a different thing though. Here are the steps: 1. refresh/synchronize the Sync view (change sets/incoming mode) 2. place other app over it (let's stick to the Windows Task Manager) 3. click directly on a change set to expand it 4. the Sync view/Eclipse gains focus but the other app gets chopped, it's still partly visible in the Sync view! it disappears after a while Not sure if it's related, but though it's worth mentioning.
(In reply to comment #0) > Synchronize view needs a lot of CPU and a couple of secs to refresh. See video. All righty, I've just seen it on OpenLinux. I wouldn't say it needs a couple of seconds, but it takes enough time to see the same white spots as in Benno's video. The CPU consumption gets high too. I guess it's 2-1, so I'm changing the status to ASSIGNED.
I profiled Eclipse to determine why Sync view acts as Benno described in comment 0. I did on both Windows (XP) and Linux (OpenLinux). I didn't notice much of a difference between results I got for builds, but just for the record it was I20080508-2000 on Windows and 3.4 on Linux. On both boxes org.eclipse.jface.viewers.StyledCellLabelProvider.paint() method took near half of the CPU time. That's why I think I should move it to UI so they can comment on it too. Screenshots and snapshots from Yourkit Profiler will follow.
Created attachment 108327 [details] Screen shot from Windows
Created attachment 108328 [details] Screen shot from Linux
Created attachment 108329 [details] Zipped snapshot from Windows
Created attachment 108330 [details] Zipped snapshot from Linux
(In reply to comment #3) > On both boxes > org.eclipse.jface.viewers.StyledCellLabelProvider.paint() method took near half > of the CPU time. That's why I think I should move it to UI so they can comment > on it too. Just to clarify, the question is: is it expected that the method takes that much time? If no, and you think there must me something in our code that causes it to act like this please feel free to move it back to us.
It could either be a problem in the paint -or- the view might be forcing too many paints...
It is strange that the Synchronize view takes so long to repaint while other views with colored labels (Package Explorer, Search) don't. Martin, do you have any idea how the Synchronize view is different and why it could be slower?
The invocation count of paint is 1'300. So my guess is that there are too many updates sent.
(In reply to comment #11) > The invocation count of paint is 1'300. So my guess is that there are too many > updates sent. But how can this be different from the number of updates sent for the Package Explorer? Try for yourself with a Package Explorer and the Synchronize view open at the same time, and move another app's window on top of Eclipse - the Package Explorer redraws noticeably faster than the Synchronize view.
(In reply to comment #11) > The invocation count of paint is 1'300. So my guess is that there are too many > updates sent. I made some further profiling having this in mind. I profiled the Package Explorer and the Synchronize view having the same number of visible items, using more/less the same time frame and doing generally the same thing (moving a Nautilus window over the view). I did it on Linux as it seems to give more vivid results (refreshes slower;) What I found is that the invocation counts of StyledCellLabelProvider.paint is comparable. Moreover, from the numbers I have here (I made 3 tests: 2x30s and 1x60s) it looks that the method is called more often for PE than for the Sync view. Of course, the measures are not 100% accurate, but none of them seem to prove the theory from comment 11. However, I'm not an expert in this area so I can be totally wrong (or may have misinterpret the results).
Time is running out on 3.4.1 - I'd suggest that we target 3.5 instead since we don't understand what's going on. From Tomasz's experiments, it seems that the problem is not caused by too many updates. If you see a smaller number of updates in the Sync view, the reason for that is probably that each update takes more time, so that in the same time span, less updates can be performed. Benno or Martin, if you have any idea on how to proceed, please let us know.
Has there been any progress on this?
(In reply to comment #15) > Has there been any progress on this? No. Benno or Martin, are you still seeing the "eats all CPU" problem with recent builds?
(In reply to comment #16) > No. Benno or Martin, are you still seeing the "eats all CPU" problem with > recent builds? > Hi Boris, No, I can not reproduce this anymore in I20090401-1325.
Thanks Benno!
