Community
Participate
Working Groups
Hi, This is a bit minor but I have noticed a very large performance degradation when scrolling in Ganymede 3.4 M5 (with all pluggins including WTP3) as opposed to the latest Europa 3.3.1.1. I don't think it is the Windows graphics library as half the pane refreshes instantly and it is the lower half that takes time - possibly HD latency? If you scroll a large number of java files in a navigator pane in Europa it is near instant, but in Ganymede the list takes about 0.25 sec to scroll. Reproduction ----------------- Windows Vista SP1, HP Core 2 Quad 2.4Ghz 3Gb Ram I can run 2 separate copies of Ganymede along 1 copy of Europa fine. The ganymede versions show the slow scrolling but the europa version is very fast when all 3 eclipse.exe versions are running simultaneously. If you need any other info, mail me and I will provide it. btw: Ganymede is running very well with WTP3 and seems to be more stable than Europa 3.3.1.1 as i do not get the occassional JVM crash with the same workspace config when running 3.4 M5. thank you
Perhaps a fallout from the use of owner draw? Do we have any performance numbers for this?
Can you turn off colored labels (Window > Preferences > Java > Appearance, uncheck "Show colored labels") and try again?
Flag set to off - sorry, no change But, these flags only affected my Hiearchy sub-pane and did not cause any visible changes to the navigator pane - which has no annotations like ": void - java.lang.Object" on the file list. Note: the "Package Explorer" view expanded out to show all java files does not have this problem, only the "Navigator" view is slow (and seems to be independent of the depth of the package tree)
Tom or Tod, do you have any ideas what could be causing this?
... we haven't changed much inside the JFace-Viewers in 3.4 and my first reaction was also to point to owner draw which doesn't seem to be the problem from what is said above. I think we need to profile the code to see where the time is spent.
I won't be able to look at this until after EclipseCon, but I think it's important to find out what's happening.
Owner draw is running with or without the colouring correct? I suspect it is the callbacks that we are getting from SWT being served - this is also an issue for VIRTUAL tables. I suspect we are filling in more often then we need to.
> Owner draw is running with or without the colouring correct? This should not be the case. If you are not doing custom draw, then everything should be as fast as it was without. Note: When you turn off "Show colored labels", you will need to restart to IDE to really get rid of custom draw.
Please adjust the target milestone, so it does not point at a closed milestone in the past.
Marking for investigation, but I am pessimistic that we can do much about it for 3.4 even if we find out that the refresh is indeed slower.
I am out of time to do anything about this for 3.4. As a workaround, you should be able to get the performance back by disabling colored labels, either from the General>Appearance preference page, or via plugin_customization.ini, or by setting the preference programmatically: IWorkbenchPreferenceConstants.USE_COLORED_LABELS Marking for 3.4.1 (and helpwanted).
(In reply to comment #3) > Note: the "Package Explorer" view expanded out to show all java files does not > have this problem, only the "Navigator" view is slow (and seems to be > independent of the depth of the package tree) Sorry, while re-reading this bug I found the above which says that owner draw is not the culprit. I have tested with a folder containing just under 4000 folders and files and could not reproduce the problem. Are you sure it was the Navigator view (and not for example the Project Explorer view)? Do you have steps with which I can reproduce? I was only using the base SDK but that should not make a difference for the Navigator view. (It would make a difference for the Project Explorer view though.)
Removing target milestone due to lack of response. It is too late to do anything about this for 3.4.1.
Sorry for the lack of updates. This no longer occurrs on production ganymede 3.4 RCx
