Community
Participate
Working Groups
3.0M8 It takes a long time to switch perspectives on Linux-GTK. Furthermore, visually we see a lot of rendering activity during a perspective switch, which gives hints as to where time is being spent. There are actually two problems here: 1. Perspective switching is slow, and 2. Perspective switching causes too much visual garbage to occur. The task to solve the first problem is to determine if we are doing too much work. I suspect yes. Can we cache views that are open in both perspectives to avoid closing and re-opening them? What if their location is the same (a good example is the Intro view)? The second problem directly involves Linux-GTK. There are some specific issues we have identified which cause visible errors: 1. The first is the problem described in bug 53791 relating to Window objects in X11. Some of this may be unavoidable. A solution worth investigating might be to make toolbar items lightweight components (avoid using gtk_set_has_window(true)). 2. We believe that the active GTK+ theme has a huge impact on perspective switching performance. The Simple theme seems to perform much faster than BlueCurve on RH9. Is this indicative of a larger problem? 3. gtk_adjustmet_value_changed and gtk_wait_for_clipboard both are called during a perspective switch, and both have a side-effect of causing the event loop to be processed. Is this causing more repaints to happen earlier than expected? 4. update() in Control is called during a perspective switch, and this also seems to cause additional renders to the screen. Is this causing repaints as well? It is at least called from CBanner.layout(). 5. Why do we see things cleared to their background colour (because we create and destroy X Window objects?)? We also used the gdk_window_set_debug_updates() function to watch repaint events. It may be worth using this some more to make sure we're never actually drawing the same place twice during a perspective switch.
Performance characteristics across changes in Gtk+ theme for perspective switching are presented in bug 37683. We should make sure that any performance tests we do use a consistent theme.
From bug 37683: To try and get a better idea of how much the Gtk+ theme affects performance, we investigated the performance of perspective switching with different themes. Test setup: I200405111600 P4 2.53 GHz 768M of memory RH9 kernel 2.4.20-30.9 and Gtk+ 2.2.1-4 We timed the performance of 100 switches between the resource and java perspectives with one editor open showing org.eclipse.ui.internal.util.Util. The event loop was allowed to spin to completion after each switch to allow repaints to occur. To be clear: for i in 1 to 100: switch to resource perspective handle events switch to java perspective handle events We ran our test once per theme and twice with the default Red Hat theme Bluecurve. Each theme below is included with RH9 with the exception of CleanIce, for which we used the CleanIce engine version 1.2.8. The theme was changed using the 'gnome-theme-manager' application. The results were as follows: Theme Elapsed Time Compared to Traditional ------------------------------------------------------- Traditional 3m23s 100.00 Simple 3m24s 100.49 High Contrast 3m25s 100.99 Mist 3m25s 100.99 CleanIce 3m26s 101.48 Crux 3m28s 102.46 Ocean Dream 3m31s 103.94 Grand Canyon 3m36s 106.40 SmokeyBlue 3m47s 111.82 Bluecurve (2) 4m32s 133.99 Bluecurve (1) 4m38s 136.95 We recommend avoiding Bluecurve. Switching from Traditional to BlueCurve shows roughly a 35% slowdown in this test. ---- For comparison, we ran the tests with our same setup on Motif. Since the GNOME theme is also responsible for the window titles, which change during perspective switch, we tested with both the Traditional and Bluecurve GNOME themes. Theme Elapsed Time Compared to Traditional ------------------------------------------------------- Motif-Bluecurve 3m29s 102.96 Motif-Traditional 3m34s 105.42 We believe that the speed of perspective switching is not significantly different between Motif and Gtk+ (assuming you are not using Bluecurve). Note that this data is only relevant for perspective switching and does not necessarily map to other operations. ---- For comparison, we also ran this test on Windows. Test setup: I200405111600 P4 2.53 GHz 768M of memory Windows XP Pro, Service Pack 1 Elapsed time: 1m30s, compared to Gtk+-Traditional 44.28% Windows seems over twice as fast for this test. This seems to indicate that the windowing system has a significant component to perspective switching. Also, the tests on both platforms were tested using the Sun VM version 1.4.2, although the Linux version is 1.4.2_03-b02 while the Windows machine is using 1.4.2-b28.
We re-ran this test on I200405181200: Theme Elapsed Time Compared to Traditional/I200405111600 --------------------------------------------------------------------- CleanIce 1m40s 49.40% Bluecurve 2m45s 81.28% Windows 51s 25.12% We have clearly improved the amount of non-drawing work we do. The gap between Bluecurve and CleanIce is now much more significant, since less time is spent rendering. We are also now twice as fast as we were in I20040511.
We also ran this test on 2.1.3 after some tweaks. The time using CleanIce was 4m19s. So, it seems we have already improved significantly.
Looking at the profilter output, it seems we are avoiding a lot of the widget creation time that slowed us down. Many other issues have already been solved: 1. As a hack exists for setRedraw (bug 53791), we avoid a lot of redraw fuzz. 2. We have profiled many themes and shown that Bluecurve introduces performance problems whiel other themes perform similarly to Motif for perspective switching. 3. gtk_adjustment_value_changed doesn't spin an event loop but merely synchronously paints, and we are avoiding spinning an event loop now for clipboard events (bug 44915). 4. Calls to update() should now be gone, and furthermore should not matter based on the setRedraw hack. 5. We still see some redraws to the background colour, but only at the end of the perspective switch and they are quick to repaint. I think we should have more concrete profiling data for perspective switching, but this can be done post M9. Marking this bug for 3.0.
Not sure if this information will help. Just downloaded M9 to try it out. Was really eager to try out if this patch would help. The problem is, when I switch between the Resource and PDE perspectives (the only two open), I can see the different widgets falling into place, like a puzzle in slow motion. Just a little bit slower, and I would be able to count the widgets one by one :) Here's my config: HW: IBM TP T30 Memory: 512MB OS: Linux 2.4.22 Gnome: 2.4 JDK: 1.4.2 Eclipse: 3.0M9 Eclipse is configured with almost everything turned off (content assist, hovering, ...)
Can you post two screenshots showing which views are open on each perspective? This would be really helpful. I think if you're still seeing things being slow that it may not be the perspective switch itself, but the rendering time for each view. As a test, try maximizing eclipse and also, say, a web browser, and just switch bringing each to the front. Does it look just as bad?
Chen Shaopeng: Any update on getting those screenshots?
Sorry, I was switching back to M7 for testing, coz there are a lot of changes from M7 to M9. But I made some changes though. Here they are: 1- upgraded to linux kernel 2.6.6 2- give much more memory to eclipse (eclipse -vmargs -Xms256M -Xmx512M) Upgrading to kernel 2.6.6 helps a little bit, but the biggest help was to set -Xmx512M. I was using -Xms256M -Xmx320M. Setting larger memory brings another problem. I only have 512M of physical memory, everytime I switched between applications, I have to wait sometimes up to 20 seconds of disk swapping. This does make Eclipse much more usable, but switching between applications becomes a big pain. I turned off most of eclipse's nice things, e.g analyze annotation while typing, hovering, limit open files to only 10 before closing, etc. And here's the info from "ps au" (if that helps): csp@cerberus:~$ ps au USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1550 0.0 0.0 1528 412 tty1 Ss+ 08:16 0:00 /sbin/getty 38400 tty1 root 1815 0.0 0.0 1528 412 tty2 Ss+ 08:16 0:00 /sbin/getty 38400 tty2 csp 1961 0.0 0.4 3500 2324 pts/0 Ss+ 08:16 0:00 bash csp 2151 0.0 0.4 3508 2340 pts/2 Rs 08:24 0:00 bash csp 2191 0.0 0.4 3508 2328 pts/2 S 08:25 0:00 bash csp 2192 0.0 0.2 8228 1440 pts/2 S 08:25 0:00 /home/csp/bin/eclipse/eclipse -vmargs csp 2193 6.3 58.0 752892 299212 pts/2 S 08:25 1:32 /home/csp/bin/java/bin/java -Xms256M -csp 2553 0.0 0.1 2528 848 pts/2 R+ 08:49 0:00 ps au Look at the memory, and this is only after half an hour of code writing, and switching between 3 perspective (see screenshots). Here's the stuff from my startup directories, no fancy things: csp@cerberus:~$ ls /etc/rc*.d/ /etc/rc0.d: K01gdm K10xsession K20cupsys K20fam S90knoppix-halt /etc/rc1.d: K01gdm K10xsession K20cupsys K20fam /etc/rc2.d: K10xsession K77ntp-simple S20cupsys S20fam S99gdm /etc/rc3.d: K10xsession K77ntp-simple S20cupsys S20fam S99gdm ls /etc/rc4.d: K10xsession S20cupsys S20fam S99gdm /etc/rc5.d: S20cupsys S20fam S99gdm /etc/rc6.d: K01gdm K10xsession K20cupsys K20fam S90knoppix-reboot ttys are limited to 2. And no memory-hog gnome applets except the calendar and desktop switcher (which can be removed as I use keys anyway). Currently running: - Eclipse M9 - Mozilla firefox 0.9 - gnome-terminal, 2 tabs, scroll buffer set to 1000 lines - chinput That's about it. That's pretty nice, but after a while, Eclipse still gets slower and slower. Right now, I can still see widget rendering when I switch perspective, although not as slow as before. Here's a subjective impression of things (per Billy's suggestion): Test 1: - Eclipse, Firefox and gnome-terminal are maximized - alt-tab to switch between the three Impression: - very nice, Eclipse just behaves like the other two, instanteneous rendering. Test 2: - Eclipse maximized, the other two rolled up - switch btween 4 perspective: Resource, PDE, CVS, Debug Impression: - Not very good. I can see the icon on the toolbar showing one by one, and the different views one after another. rgds
Created attachment 11340 [details] Debug perspective
Created attachment 11341 [details] PDE perspective
Created attachment 11342 [details] Desktop
It sure sounds like something is leaking memory on your system. Thanks a lot for the detailed information, I will try and reproduce based on this. Just looking at your screenshots I have some quick questions. 1. I noticed that your X server is using a software cursor. I am really curious now as to what X driver you are using, and what version of the X server it is. Can you maybe post your /var/log/XFree86.0.log file? 2. What GNOME theme are you using? There are some interesting things about how it is rendering some widgets. Can you also try using the 'Simple' GNOME theme? Even better, switch to simple and restart eclipse, and give me your impressions of switching perspectives.
I also suspected memory leak. It's not normal that it's using so much memory: I just start it up, and it's taking almost 300MB. 1. XFree86 4.3 (see log attachment), graphic chip is Radeo Mobility 7500. 2. I'm actually using the Simple theme, except that it's a little "customized". I changed the controls to Industrial theme, coz I find the high-lighting of Simple theme use a darker blue color, with black fonts. It's very hard to read, but I like the border style. So, yes, it's basically Industrial theme with Simple border style, normal Gnome icons. Changing to pure Simple theme is much better. But it also degrades quite fast. The two most used perspectives are PDE and Debug. I tried switching between these two very quickly, and I can see some parts of the screen are in PDE and others are in Debug perspective. It sure is nicer than the mixed Industrial theme though. And here's the memory usage after 5 minutes of testing (just switching, with the initial project building at startup): csp@cerberus:~$ ps au USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1550 0.0 0.0 1528 268 tty1 Ss+ 08:16 0:00 /sbin/getty 38400 tty1 root 1815 0.0 0.0 1528 268 tty2 Ss+ 08:16 0:00 /sbin/getty 38400 tty2 csp 1961 0.0 0.0 3500 428 pts/0 Ss 08:16 0:00 bash csp 2151 0.0 0.3 3508 1704 pts/2 Ss 08:24 0:00 bash root 3340 0.0 0.0 3452 332 pts/0 S+ 13:34 0:00 -su csp 3395 0.0 0.1 3508 644 pts/2 S 13:42 0:00 bash csp 3396 0.0 0.1 8228 1012 pts/2 S 13:42 0:00 /home/csp/bin/eclipse/eclipse -vmargs csp 3397 21.2 64.5 746120 332220 pts/2 S 13:42 1:56 /home/csp/bin/java/bin/java -Xms256M -csp 3472 0.0 0.1 2528 848 pts/2 R+ 13:51 0:00 ps au Here's my normal working environment (in Eclipse, that is): - about 20 plugin projects open at the same time, - about 10 third-party libraries (e.g. apache, springframework, castor, ...) packaged as plugins - 3-4 eclipse plugins, mainly source codes of eclipse plugins for debugging and tracing) - 2-3 simple projects for project documentation (not Java) - customized ant build scripts - CVS repositories (internal CVS repositories, Eclipse, JBoss, Apache, and sourceforge.net). - most used perspectives: PDE, Debug, CVS, CDT, repository synchronization That's it.
Created attachment 11345 [details] XFree86 log
I haven't had time to try and reproduce your problem specifically, but there were two interesting things I noticed in your X log that I thought I would mention: 1. (WW) RADEON(0): Failed to set up write-combining range (0xe8000000,0x1000000) This is bad. MTRR support is very important for video card performance for all of X. Did you recompile your kernel and forget to enable MTRRs? It's 'Memory Type Range Register' support in the kernel config, and it's a common cause of X slowdowns. 2. (**) RADEON(0): Option "SWcursor" Why are you using the software cursor? Won't this slow things down? Is there a bug in your hardware you're working around? I'm just curious, I don't think it will have a huge impact.
1. Hmm... not an "Xpert" myself, I have no clue what MTRR does to X performance. I didn't compile the kernel myself, I just apt-get it. Seemed to work for most functionalities, and didn't spend time fixing those that do not work yet (sound, acpi, usb mostly broken). I'm back to my old kernel (2.4.22), and here's the info for mtrr: [csp@cerberus:csp] cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x1ff80000 ( 511MB), size= 512KB: uncachable, count=1 reg02: base=0xe0000000 (3584MB), size= 64MB: write-combining, count=1 reg03: base=0xe8000000 (3712MB), size= 16MB: write-combining, count=2 Not sure if reg01 being uncachable has any effect. 2. I'm not sure this has much to do. The nice thing about hardware detection now is that you just install, it detects the hardwares and set them up, and it just works. So I didn't do anything in the X config, except setting the capslock-ctrl swapping. I'm now back to my old kernel, as the new one has a bunch of other problems. The pre-emptiveness of the new kernel is nice though, especially when you have to do some IO-intensive work, it feels much better on the UI level. When we are done with our own product release, I'll take a look into recompiling my own kernel and see what would happen. Right now, M7 is working fine, except a few minor issues. Please let me know if you need some other debug info for M9 on 2.4.22. Thanks for all the work.
Sorry that I had not responded yet. Chen, I think your problems are related to a memory leak and not to perspective switching itself. Please try out RC2 and file a new bug if you are experiencing the same problems there, I think it will be easier to track. I am going to close this bug since we have made a lot of measured improvements since M8 in terms of perspective switching performance (also see bug 65269 which helps out here as well). While I think we can continue to improve the performance of perspective switching under Linux, much of the discussion from this bug report has been resolved or is at least better understood.
