Community
Participate
Working Groups
Install Eclipse 2.1 M4 on the mac. Open a java editor on a java class with multiple methods. Go to the default Java Perspective. Click on a method in the Outline view. Click on a second method in the Outline view. There is a noticeable delay when updating the editor to show the selected method. Install Eclipse 2.1 M3 on the mac. Replace the org.eclipse.swt.carbon plugin with the M4 version of org.eclipse.swt.carbon. Repeat the steps above. The time to update the editor is noticeably faster. I do not have numbers to put to the time differences, just observation.
Adam, can you please measure M4 and compare the results against M3.
We have already tried this, hacking way down deep in the SWT tree widget by printing the time taken servicing the SWT.Selection event. The times that were printed out did not seem to reflect the wait. It's quite possible that I got something wrong doing this. Does the JDT code run in the UI thread? Does it run in sync/async execs? Does it run in another thread? Adam, you should answer these questions and try and recreate my hacking so that we have some hard numbers. If you have any other suggestions, I'm open. Thanks.
will have a look
yup, it does appear to be slower (when you use arrow key to navigate) looks like StyledText.performPaint is now either 2 times slower than on M3 or it's called twice as often will attach 2 profiles
Created attachment 3041 [details] outline clicking on M3 (test case is going thru all methods in junit Assert class)
Created attachment 3042 [details] same on 20030115 same test case
Created attachment 3043 [details] outline clicking on 20030115 (expanded a bit) maybe it's GC.drawString, actually
Created attachment 3044 [details] outline clicking on M3 (expanded to the same level) GC.drawString takes now twice as much as time on M3
back to SWT - looks like it's not jdt (jdt's stuff takes now 7% compared to StyledText 40%) please bounce back if you think otherwise
We know that with Core Graphics versus QuickDraw there is a 2x slow down. However, there is more slowness than that. If you use the exact same version of the SWT jar (which includes StyledText) then you can still see a slow down between M3 and M4 when clicking between methods (see original description of the problem). That is what this PR is meant to focus on. Sending back to JDT UI.
Guys, stop the bounce and get to the bottom of it. We know that string draw is slower in Core Graphics vs Quickdraw. If string draw is actually the cause of the slow down, then there are two things we can do. Optimize string draw in SWT (has already been done once by SSQ but there may be more we can do) or make sure that JDT or StyledText or whoever is not calling string draw too many times. Before investing time into this, I would comment out string draw (and string measure?) making this operation take zero time and then compare the results.
note also that i do not any slowdown when clicking between methods using the mouse, only keyboard
Veronika, what do you mean by 'clicking'? Is it with the keyboard or mouse. We asked Kai and the little delay when using the cursor keys is on purpose (to avoid redrawing when the arrow key is held down). So, if that's what you mean, then we can close as 'worksforme'
I mean clicking with the mouse.
i see no speed difference on windows maybe it's mac X specific asking Andre Andre, can you please have a look and comment if you perceive any difference in the described scenario?
Perhaps Windows is not a good reference platform because it is quite fast (graphics calls are much faster than on any other platform) and small differences will not be noticeable. How about motif on linux or GTK on linux?
Adam, look at the OS field. The slow down is on MacOS X. If you have been testing elsewhere, you have been wasting time. Please redo your tests on MacOS X. Thanks.
Steve, i do not have access to Mac os X here only Andre does
nothing i can do here back to inbox
Veronika, what do you want to do? It's critical that we address this.
Steve, since the SWT team has most experience with Mac OS (and the necessary hardware) it would be nice if you could provide the necessary performance tests. We can only ensure that JDT UI didn't slow down in general, what we did by testing the performance on Windows. If there are special issue with Mac OS they might be useful for other plug-ins as well.
Ok, can you comment on my questions/observations from before: "We have already tried this, hacking way down deep in the SWT tree widget by printing the time taken servicing the SWT.Selection event. The times that were printed out did not seem to reflect the wait. It's quite possible that I got something wrong doing this. Does the JDT code run in the UI thread? Does it run in sync/async execs? Does it run in another thread?"
Basically, I hacked way down deep to get some timings and they didn't reflect what I was seeing and feeling in the UI.
The Outliner uses post selection change listeners, which are provided by the JFace. The have some sort of delay when selecting with the cursor keys. Carboning Daniel and Kai-Uwe about the question if some of the code triggered by selection changes in the outliner are processed asynchronously. The know most about that code.
Moving to Platform SWT. Some benchmarking comparison M3 2 to 4 times faster than I20030121 M3 comparable to I20030121 with fake GC.stringExtent, fake GC.drawString M3 with fake GC.stringExtent/drawString still 2 times faster than I20030121 with fake GC too Details - eMac PowerPC G4 800Mhz OS X 10.2 - Instrumented JavaEditor.setSelection (org.eclipse.jdt.ui plugin) - Self Host - Maximize Eclipse - Same runtime workspace with same file ImageData - switch to first constructor, then 2nd etc until 4th in method outline view Each line: (average result per method) [time to switch to first method] [time to switch to second method] [time to 3rd] [time to 4th] in milliseconds M3 (152) 295 69 139 103 (103) 100 70 134 107 I20030121 (386) 185 538 420 400 (322) 176 372 395 344 M3, SWT I20030121 (375) 247 444 418 388 (375) 168 547 405 381 *1 fake GC.drawString *2 fake GC.stringExtent I20030121 *1 *2 (122) 110 124 117 138 I20030121 *2 (251) 139 298 309 258 M3 *1 *2 (66) 81 62 60 61
Did you try "Quartz Debug"?
*** Bug 30695 has been marked as a duplicate of this bug. ***
Moving to Silenio
Clicking case has been improved. There are still other areas.
*** Bug 31560 has been marked as a duplicate of this bug. ***
In my previous implementation of SWT I could improve typing performance of Eclipse by removing the (under Quartz totally uneccessary) double buffering in StyledText. Today I tried that again but I wasn't able to get identical drawing (and scrolling) behavior after uncommenting double buffering. Any low-hanging fruit in that area?
We already hacked that and it makes no difference.
We have made some improvements in the latest. The current theory is that mixing Core Graphics and Quickdraw calls makes things slow. We have absolutely no proof of this at all and unfortunately, the only way to really prove it is to put back Quickdraw which is lots of work. Unfortunately, Mac performance work is getting in the way of finishing off the native table and tree. The tree is very close. Can you get the latest and retry? We need to decide whether the current performance is good enough for now. We would continue the work, but after 2.1. Your thoughts?
Current typing performance on my PowerBook 800 is quite acceptable. I'm doing 98% of all my development there and I do *not* consider it "a pain". However, the real show stoppers right now are: - jumping characters and rounding errors which result in off-by one caret position errors (#28514) - Trees are not compact enough or cannot be made compact enough partially because of #28739; so when trying to get the native tree ready, please make sure that it doesn't not waste even more space than the existing tree, and if it does, provide a way to let users switch back to the emulated tree).
Check also comments in bug#30768.
Downgrading this to P2. Performance is now acceptable. We'll work more on this after 2.1 ships.
Is it appropriate to put the overlong delay when cmd-space-ing after a variable. here? If not, let me know and I will create a new bug report. Release 2.1 is slower than I would like when performing a command-space on my TiBook 667/1G/ 48G. It can take two seconds for the context menu to appear in a case like: String foo = new String(); String bar = foo.<cmd-space here> Similarly, RS_<cmd-space> brings up a pick list of 95 possible classes. This takes about two seconds. RS_Evidence e=new RS_Evidence(): e.<cmd-space> also takes about two seconds. That class has 121 methods. It takes about a second and change to do the same on a class in the same package (RS_Phone_Number) that has only twelve methods. So, it does not appear to be linear in the number of classes or methods, at least for under a hundred or so choices. I have not made any changes to eclipse or its startup parameters since installing it, though I do have a number of projects in my workspace that have moved forward from 2.0.1, M3-M5, and the RCs. Since there are fifty of them, I would rather not delete and recreate them unless there is reason to believe it will help.
There is a separate bug for this Bug#33492.
33492 is actually not appropriate for delays in cmd-space, as 33492 affects only error messages. Based on this, though, I believe the slow appearance of the popup is not related to the outline clicking, and will thus open a new bug. Thank you for your time.
We improved menu item creation performance (setting text, accel, etc) by removing calls to GetIndMenuItemWithCommandID() (which is really slow). Clicking between views is much faster now (specially between the outline view and the editor).
We have made lots of performance improvements for 2.1.1. Please get this or a nightly and let us know what you think. There are always more things we can do. Are there any particular areas that we should look at again. Thanks.
It has definitely gotten better since 2.1 - I tested with 20030520. The outline view is rather sprightly. I can still outpace it with a flurry of mouse clicks, but it is definitely more usable now. Good job! I made a few more tests in support of 36732 (cmd-space popup too slow to appear), as that is still draggier than I would like, but the progress on 29642 was very heartening. I am very encouraged. Scott
I can second Scott's comments. Build 20030520 is definitely going in the good direction! Keep up the good work. Ringo
Performance of the Mac port in general was addressed in R3.0. Please open specific bug reports if you still have cases were performance is not acceptable.
