Community
Participate
Working Groups
since 3.0M8 typing is terribly slow, for example if I want to add a new line, and I type <Enter> then the effect is that the line on which the cursor was, is duplicated, then a few seconds later the new duplicated line will become gray (to indicate that it is selected), and then after a second the cursor will return and I can continue typing.
Moving to Platform/SWT for comment. Perhaps related to changes in StyledText? Ruth, were you using a Java Editor or a regular Text Editor?
Try turning off all Java Editor options - I mean EVERYTHING. Is it still slow? Is typing slow in the StyledText tab of the CustomControlExample?
This happens both in the java-editor and also in the regular text editor.
about the StyledText tab of the CustomControlExample, I don't know where to find that.
CAR, can you help this guy run the CustomControlExample?
Hi, Ruth. I am also curious which Linux platform you are running on. To run the CustomControlExample, please go to this link, and follow the instructions in the "SWT Examples" section. http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt- home/SWT_Resources.html CustomControlExample is a plug-in example (it can also run stand-alone, but the easiest thing for you to do is to follow the plug-in example instructions). After launching the CustomControlExample, go to the StyledText tab. This is the eclipse java editor widget, without all of the java editing "extras". To make the StyledText in this example have a few more lines, just type in several more lines, and then change the size to "100 x 100" and back to "Preferred". Please let us know if this widget has the same slowness that you are experiencing in the java editor.
NOTE: Do not run it as a plug in. This will defeat the purpose of the experiment (ie. is typing slow in stand alone SWT or in Eclipse).
Actually, both standalone and plug-in will tell us something. If StyledText runs fast when running CustomControlExample as a plug-in, then it is the java editor goo that is making StyledText slow. If StyledText runs fast when running CustomControlExample standalone, then it is the hooking of global accelerators for all of eclipse that is making StyledText slow. If StyledText is still slow when running CustomControlExample standalone, then it is our changes to StyledText that are the culprit. I have just talked to the guys that made the StyledText changes, and they say they have made some performance improvements since M8. They also ask if it is really long lines of text that are very slow when you hit <Enter>. They have not seen this kind of terribly slow behavior, but they are on fast machines, running Linux Red Hat 9. Reassigning this bug to FH at the request of SSQ.
Ruth, are you running GTK or Motif ? GTK is faster than used to be, so I suppose you are running motif. You also could download this week integration build (which will be build tomorrow morning) and give it a try, it is much faster than M8.
1. the problem occurs on both gtk and eclipse. 2. I have tried the custom control example as plugin, and that is much faster. 3. I also tried to run this as stand-alone, but I must have done something wrong, for I get: java.util.MissingResourceException: Can't find bundle for base name examples_control, locale en_US 4. I don't think it has to do with long lines. 5. Also I must add,that it is not *always* slow, I have tried to figure out when exactly it is slow, but I have not yet seen a pattern. 6. my linux platform: gentoo linux Linux i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux 7. I run eclipse on a remote computer (with ssh). the information at point 6 is about this remote computer.
at point 1 in my previous comment I meant gtk and motif of course (not gtk and eclipse)
Did you try the new integration build (Integration Build: I20040407 )?
FH, this has nothing to do with SWT (typing in ControlExample plug-in was not slow). Please move this out of SWT and reassign bug ownership (unless you disagree of course). Thanks.
Tom, did you notice this (degradation also on Text editor)? Ruth, >5. Also I must add,that it is not *always* slow, I have tried to figure out when >exactly it is slow, but I have not yet seen a pattern. might it be when you have lots of stuff highlighted in text (e.g. when having search results)?
No, I haven't seen any degradation in M8 or after. > 7. I run eclipse on a remote computer (with ssh). the information at point 6 is > about this remote computer. Could this make a difference? I am not sure about how good we are running on a remote X server - even with good bandwidth frequent updates might cause problems. This could also explain why it's sometimes slow and sometimes isn't: that may well depend on the delay experienced on the network. Carolyn, do we have any measurings of running eclipse remotely.
Steve, please read comment 15 - does anyone run eclipse over ssh?
Ask Felipe or SSQ. They have done this in the past.
I done this on the past (like one time 6 months ago), I really don't remember how fast/slow it was. I asked to Ruth (reporter) to retested this problem with a newer version of Eclipse (see comment12). We disabled double buffered for gtk/carbon and we started to cache glyphs/metrics for the visible content of the StyledText. StyledText performance is much better now (uses more memory though). Is anti-aliasing enabled ? Does it make any difference ?
FH, please try again. Be sure to distinguish between typing in a stand alone SWT example and Eclipse. Thanks.
I'd like to add that I'm seeing the same. I'm running on Gentoo with 3.0M8 and JDK 1.4.2.04 from Sun. I've noticed that I can type for a while with no problems then all of a sudden, things will start bogging down tremendously. I will type a line and the text will appear 5-7 seconds later. It usually occurs after a few minutes of usage (maybe 60). L
Re: comment 16: >>Steve, please read comment 15 - does anyone run eclipse over ssh?<< I've run in the cartesian product of all of the following configurations: (Eclipse, Standalone SWT)(Naked X protocol, X tunnled through SSH) Informally, here's what I've observed: - Lightweight SWT controls tend to perform badly over X--both pure X and tunnled over SSH. - GC.drawText() performs terribly if antialiasing is on. Turning antialiasing off using the XFT environment variable makes GC.drawText() perform beautifully. When using an X terminal, you can see a huge amount of network traffic when doing GC.drawText() with antialiasing on simply by watching the activity LEDs on the network card. I've traced the code down to the Pango calls used by #drawText() and it seems that Pango is rendering the text into a pixmap in the X client, and then sending the pixmap to the X server. This is obviously very inefficient. I have no idea if there is a way to make GTK/GDK do antialiasing in the X server if that is available, but this would greatly improve performance. - On my 10MBPS LAN, Eclipse 2.x and 3.0 up to M4 (haven't tried later than that) performs miserably on X terminals. By "miserably", I mean that typing in the Java editor refreshes approximately every *second*. Other actions--picking menu choices, running dialog boxes, using list boxes, etc--perform acceptably. - Occasionally I forget to commit changes I've been working on at home (under Linux) to CVS at work. In that situation, I SSH from my work machine (running Cygwin/X on Windows 2000) back to my home machine. At work, we have a T1. At home, I have a decent-sized ADSL connection with slightly less bandwidth than a T1. When I do this, Eclipse is almost entirely unusable. Everything--menus, native GTK controls--everything can be seen drawing. Similarly, SWT standalone apps are unusable. However, Emacs runs fine once it starts up--which takes awhile. However, if i run the DXPC X protocol compressor, then both Eclipse and SWT applications run reasonably--except for the Java editor or my custom control that uses #drawText() when antialiasing is turned on. I wish I could provide more detail, but I hope this helps.
David, when you say you are using X terminals, what hardware specifically or what version of the X server? When you notice Pango rendering its antialiased text to a pixmap, it is likely because the X server you are talking to does not support the RENDER extension for server-side compositing, and so this is its only fallback. I'm specifically curious about your 10Mbps LAN cases. What is the hardware in question there?
>>When I do this, Eclipse is almost entirely unusable. Everything--menus, native GTK controls--everything can be seen drawing. Similarly, SWT standalone apps are unusable. However, Emacs runs fine once it starts up--which takes awhile.<< I should clarify this. The only standalone SWT application I've tried over this connection is one that heavily uses lightweight controls using #drawText(). So I'm not saying that all of SWT performs miserably in this situation.
>>David, when you say you are using X terminals, what hardware specifically or what version of the X server?<< I have an older machine running Mandrake Linux and XFree86 3.3.6 in a thin client configuration for my main workstation/server. (Yeah, it boots from the hard drive, not over the network.) >>When you notice Pango rendering its antialiased text to a pixmap, it is likely because the X server you are talking to does not support the RENDER extension for server-side compositing, and so this is its only fallback.<< Certainly this is a possibility. I have no idea what versions of XFree added support for XRender... >>I'm specifically curious about your 10Mbps LAN cases. What is the hardware in question there?<< My 10Mbps LAN has 3 machines on it--the main server, the Mandrake box, and a custom MP3 stereo that I built from spare parts. All of my tests have been run when the MP3 stereo box was *not* streaming any music over the LAN, so there was effectively a dedicated 10MBPS connection between the server and the Mandrake box. The two machines are connected via a hub, not a switch. (Although I have several switches--for example, built into my firewall--I've noticed that connection setup/teardown is *much* slower through a switch than through the hub. Since the next/prev buttons my MP3 stereo client rely on low latencies during TCP connection setup/teardown, I've stuck with the hub.) The server is using an Intel EtherExpress Pro card. The Mandrake box is a Pentium 2 266Mhz laptop and is using an Apollo 10/100 PCMCIA card. I have no idea what brand the hub is, but it seems to perform decently.
>>I have an older machine running Mandrake Linux and XFree86 3.3.6 in a thin client configuration for my main workstation/server.<< The older box is the thin client, not the server. ;-)
RENDER support was added in X 4.0.2, so for any X 3.3.6 client you will have to render text to a pixmap. Also, remember that the X server does actually do work, so having such a slow machine as your client won't help. :)
>>so having such a slow machine as your client won't help.<< Hey! In its day, *that* machine rendered 3d scene graphs using Mesa! (Simple ones, at only a few frames per second). ;-) Seriously though, that machine has always had decent accelerated 2d graphics, especially under Linux. And OpenOffice and Mozilla currently perform fine on it in X terminal mode (haven't tried the local configuration).
looks more like a general platform ui/swt than an editor problem
I don't think this is a general gtk or ssh problem, for I have returned to using eclipse3.0M7 which doesn't have any of these problems at all.
I ran I20040420 over ssh to a remote machine. The X client was a P3-733mhz and the appliaction was launched from a P4-2.5ghz over a fast LAN. Performance seemed fine and I did not notice any major slowdowns. Definitely not as bad as what Ruth describes. I did see the behavior of hit enter, see line doubled, then see line cleared. This occured only on the first time I hit enter, the rest were snappy. It was about a second before the line was cleared. Maybe this might be a worthwhile test case to watch the X traffic of and see if we're making too many requests ?
I attempted to measure the amount of X traffic between M7 and M8. The goal was to determine if there was a significant increase in X calls between the two versions, and also to look at the amount of data. I did not look at the difference in the types of requests being made, simply how many events and requests occured, and how large they were. I used the X protocol monitor 'xmon' with patches from Debian. The test was performed on a RH9 machine, Gtk+ 2.2.1. Test case: On both eclipse M7 and M8: 1. Create a fresh workspace. 2. Create a new Java project. 3. Create a new Java class, it is initialized to default text. Then I ran each in 'xmon', enabling viewing of requests, events, and errors. In each I did the following: 1. Start eclipse. 2. The editor for our new java class is active, scroll down to the line with the class declaration. 3. Hit 'END' to go to the end of the line. 4. Hit enter to start a new line. 5. Go to file -> quit. 6. Hit deselect all and OK when the 'save changed files' dialog appears. 7. Eclipse exits. Each test took about 30 seconds to run. Here are the request and event counts: 1. X requests: 20751 with M7, 19894 with M8 2. X events: 2965 with M7, 2993 with M8 So I don't think we're seeing a large increase in the number of requests made. I think this implies that there is not a signifiacnt increase in the number of X requests between the two versions. Here is the byte counts: 1. Client -> Server: 1509476 bytes with M7, 4845348 with M8 2. Server -> Client: 214500 bytes with M7, 224744 with M8 So we're sending more than 3 times as much data to the X server. This is likely where the problem is. We're seemingly not doing a lot more work, just sending a lot more data. To move forward, I will try and look at which X requests are sending a lot of data, and see where they are from. Note that I'm also not distinguishing between startup cost and cost of running, these numbers all include the startup time when we have to upload our gradient images and all that. It may be worthwhile to look at X traffic just from the middle of an active session.
Created attachment 10066 [details] xmon log from Eclipse M7
Created attachment 10067 [details] xmon log from Eclipse M8
Created attachment 10367 [details] Wire images from M7, M7+newlook jars, and M8 I extracted the raw images being sent over the wire between M7, M7+newlook jar files, and M8. Attached is a set of images over about 10k from each run. With both M8 and M7 with the new look jar files, we're uploading some really large gradient images. All of the gradient images for the tabs in M7 were much smaller. M8 sends almost twice as much image data over M7 using my (admittedly over-simplistic) test. If there is a way to cut back on the number of gradient images sent to the server, or just make them smaller, it may be worth it for remote users of eclipse.
BB to build a patch that disables gradient in Eclipse. Once this patch is installed, we can then determine whether too much data over the wire is responsible for the slow down you are seeing.
Created attachment 10370 [details] Patch to disable gradients Ruth, can you try this patch and see if it solves your speed problems? This one-line patch simply disables gradients and decreases eclipse's X traffic a lot. It makes some text difficult to read but if this solves your speed issue it would help clarify where the problem is.
I don't know how to apply this patch, I suppose I would need the source-code from eclipse for that. Would it be possible for you to compile this and send me the jar-file, so that I put that in the plugins-directory (I suppose that's where it should go in the end)?
Created attachment 10394 [details] swt.jar with all gradients disabled Here is a copy of swt.jar for eclipse-M8 which has gradients disabled. Put this file in the plugins/org.eclipse.swt.gtk_3.0.0/ws/gtk directory, first making a backup of the swt.jar file that's already there. I think this jar file will only work with M8.
Created attachment 10437 [details] error log error log when I use the swt.jar
When I use this swt.jar I get an error, I've attached the errorlog. Before I tested this jar, I installed 3.0M8 again, and I looked if the typing was still this slow, I noticed that it is particularly bad if I type in a file that I just opened. So for instance, if I have two tabs, one for foo.java and one for bar.java I type in foo.java, first it is slow, but after one line it gets better. Then I click on the tab for bar.java, and again the first line is slow, but it gets better. I don't know if this information helps, nor if this is *always* like I just described.
The error indicates that the jar file cannot be opened. Is there a permissions problem, or was the download somehow corrupted? I downloaded it here and it seems to be OK...
with this no-gradient swt.jar eclipse is _lighting_ fast :-) even over remote X11 sessions. I hope there will be also a way to get this kind of swt.jar for futher versions of eclipse :-) [maybe separate download for it on main download page?]
Indeed I got a corrupt swt.jar when I downloaded it with mozilla. I've now got the swt.jar with wget, and this worked. Also it does indeed solve the problem. It works perfect now.
Moving this bug to SWT. The question is whether we are sending more data than is necessary? Or are there some other ways to optimize this scenario.
Interesting that gradient should affect typing. Are we drawing it more than we should? VI to investigate with SSQ and SN as necessary. Both Ruth and Adam confirm that Eclipse is faster. Ruth and/or Adam - Is typing really faster or does Eclipse just feel faster?
Yes it's really much faster. Please see the first description: it really took seconds for the screen to update itself after I hit enter to create a new line. And this behaviour is probably worse when I just opened a new file (see comment 40)
I replaced the swt.jar file and after working a few minutes with it, eclipse crashed. Ater I tried to restart it, I kept getting this error: !SESSION May 11, 2004 09:41:23.115 --------------------------------------------- java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US !ENTRY org.eclipse.osgi May 11, 2004 09:41:23.116 !MESSAGE Bundle reference:file:/usr/local/eclipse/plugins/org.eclipse.jdt.debug_3.0.0/ [29] was not resolved !ENTRY org.eclipse.osgi May 11, 2004 09:41:23.119 !MESSAGE Bundle reference:file:/usr/local/eclipse/plugins/org.eclipse.debug.ui_3.0.0/ [57] was not resolved !ENTRY org.eclipse.osgi May 11, 2004 09:41:28.644 !MESSAGE Application error !STACK 1 java.lang.NoClassDefFoundError at org.eclipse.ui.internal.WorkbenchConfigurer.declareImage(WorkbenchConfigurer.java:92) at org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.declareWorkbenchImage(IDEWorkbenchAdvisor.java:942) at org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.declareWorkbenchImages(IDEWorkbenchAdvisor.java:860) at org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.initialize(IDEWorkbenchAdvisor.java:182) at org.eclipse.ui.application.WorkbenchAdvisor.basicInitialize(WorkbenchAdvisor.java:156) at org.eclipse.ui.internal.Workbench.init(Workbench.java:787) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1513) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:257) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:90) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:277) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:239) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:267) at org.eclipse.core.launcher.Main.run(Main.java:692) at org.eclipse.core.launcher.Main.main(Main.java:676) Now Eclipse is unusable. I suppose deleting the workspace should fix it but if someone has a better idea befor I do this, please speak up! :-) L
I need to understand this better. When you type a key it is not causing the gradient to be drawn. What we believe is happening is that when you first open an editor (or you first switch the focus to an editor from either a view or another application) this causes the gradient to be drawn. If you start typing while the gradient is still being drawn, the keys typed will not actually be processed by the OS until after the painting of the screen has completed. To confirm that this theory is correct, Ruth can you please do the following. 1) Go back to the original swt.jar that was included in 3.0 M8 2) Open an editor and give it focus by clicking in it but do not type any keys 3) Wait for 5 minutes without doing anything on that machine 4) Start typing in the editor When you type in the editor in step 4, is typing slow or fast? 5) Now click on a view and click back on the editor (this causes a gradient colour change) 6) Immediately start typing in the editor Is typing now slow or fast?
*** Bug 59014 has been marked as a duplicate of this bug. ***
okay, I've done these tests with the original swt.jar First of all: it matters a lot if these files have been saved before or not. For if they have pending changes a * is drawn in the tabheader and I think that that also causes the gradient to repaint. So I open a view files, type something in each of them, and then start the sequence of test as proposed. At point 4: it still takes quite a while before you actually see where you clicked, and the cursor starts blinking, but then after that the typing is fast. At point 6: the same behaviour as at point 4. If I do the same tests with files that aren't edited yet, then both 4 and 6 take as slow as described earlier. I noticed in the meantime that there is also some flickering in the package explorer if I save a file (the cvs-attributes disappear and appear again)
Another data-point: Using a 768/1.5M connection, the DXPC X protocol compressor, and the CygWin X server (which is a recent version of X), Eclipse is *almost* usable using the no-gradient version of SWT.jar. I can still easily out-type Eclipse in the Java editor, but everything else is now fast enough to be barely usable in this configuration. By comparison, OpenOffice.org nearly keeps up with my keyboard autorepeat, which is set as fast as possible, and *easily* keeps up with my typing speed. Of course, both applications take forever to come up, but once up, OpenOffice.org is very usable for anything I want to do in it, but Eclipse (with the gradient-free SWT) is only usable for things that don't involve typing Java code.
David, see comment #10. Can you try the StyledText in the CustomControlExample? It was "much faster" for Ruth. Next try turning off all of the JavaEditor features in Eclipse. Does typing get faster?
Ruth, In the latest integration build (I20040512) I have reduced the number of times the gradient is drawn to the bare minimum. A gradient is still being drawn but much less frequently and the size of the area being filled in is much smaller. Can you please try this latest integration build and see if the performance is acceptable? Thanks.
Steve, I didn't get to the StyledText test you suggested last night (had a honey-do list that kept me up until almost midnight), but one thing I notice when using Eclipse running at home, but displaying here is that every character in the Java editor that is not drawn black is drawn at least twice. ie: I can see it appear in black, and then its color changes to the keyword color, quoted string color, etc. The black characters might be doing the same thing too, but I couldn't verify that visually. I'll definitely try to do some testing with StyledText today or tomorrow and see if I can pinpoint any issues with it or with how it is being used in the Java editor.
I tested I20040506 versus I200405111600 in terms of image data sent using the steps I described in comment #31. I recorded a decrease of 33% in the amount of image data sent: 3844k down to 2604k. This decrease is especially significant considering that this includes the splash logo, all icons, and Gtk+'s fancy animated cursors.
I tested I200405111600, and it is indeed much better. Great!
I have got this problem on Eclipse 3.0M8 for Windows. I am using Windows XP SP1 but I think it is the same origin in source code. Is there already a patch for Windows (like this for Linux)? Thanx in advance. p.s.: I have made an update for this linux bug because I have not found it for Windows. If there is already a bug report for Windows please excuse me.
Ruth, can we close this bug report?
PhoenixBB, the fix is X specific. Sorry.
yes, and thanks for all the good work.
Fixed > 20040513
