Community
Participate
Working Groups
Hello folks! Great Work you are doing! But unfortunately, in Linux VE can't be utilized properly due a extreme slowness. I needed to format a partition in my HD and install Windows XP in order to utilize VE properly. There it goes like a bullet. But, as a Linux user, I think the performance in Linux should be similar as it is in Windows. My PC is a Sempron 2500, with 512 RAM, 80 GB HD. My Linux partition have the Gentoo Linux, with 2.6 kernel and Sun's JDK 1.5.0_04. The fact is that I took one hour to create a menu bar with three menus. I tried to change the VM to the 1.4.2 but there was no difference in performance. But in windows XP (on the same machine), with Sun's JDK 1.5.0_04, it runs very fast. Do you have any clue? What could be the problem?
We've tested VE 1.1 on Linux RHEL 3.0, and SUSE 9.0 and I haven't seen any major performance problems albeit does run slower than Windows XP. But I think all are machines have 1Gig RAM in them which might make a difference. Is there another machine you could try this on to confirm this? Also, could you provide some rough measurements and scenarios as to what you describe as "extreme slowness". Is this startup time when you open the editor? Or when you drop components from the palette? Typing in the source viewer? Are you using just Swing... or SWT too? Please provide more details. Thanks... Peter Walker.
Also, just wanted to ask if you are doing this through some remote X11 display? Rich was doing it through remote display and Swing was taking an awful amount of time to paint the widgets. The same wsa not observed with SWT i think.
"But I think all are machines have 1Gig RAM in them which might make a difference. Is there another machine you could try this on to confirm this?" No I don't have other machine with linux, but I think it isn't needed, because I watched the "memory in use graphic" from my OS, and it jumped to 200 to 300 mb when I started and used VE, so, there was no paging. The slowness shows up when I drop components from the palette; and when VE refreshes the view when I type in source viewer. I'm using Swing only. It takes something around 3 seconds or more to show the properties of a selected item in the view. More 3 seconds to update the code. No remote X11 display. I'm using everything in a single desktop, with no network. It can be a issue from newest kernel or xorg versions: Kernel is 2.6.11 and Xorg 6.8.2. RHEL 3.0, and SUSE 9.0 that you've tested use Kernel 2.4, I think. And probably older Xorg-Xfree verions. Maybe there is the problem if in these distros you doesn't noticed any major performance lack.
(In reply to comment #3) > The slowness shows up when I drop components from the palette; and when VE > refreshes the view when I type in source viewer. I'm using Swing only. It > takes something around 3 seconds or more to show the properties of a selected > item in the view. More 3 seconds to update the code. Sri, I'm not sure if this is your area or Rich's area but the time to display Swing components in the property sheet view does indeed take 3-4 secs on my machine (SUSE 9.0). I created a class extending JFrame and just dropped a JCheckBox and a JLabel into one of the regions of the content pane. When dropping from the palette, after you drop the component, the time to actually show the graphic in the graph view takes 2-3 secs also. This only takes about a second a WindowsXP. Interesting though is if you select the JFrame, the PS only takes a second. Other containers such as JPanel and JSplitPane take a little longer (2 secs) but the basic Swing components such as JButton, JLabel,etc. take the most time to display in the PS. Note: This is not a problem with SWT controls or composites.
We know that there is slowness in getting the image for Swing components. Bug 71278 is there to track that. Since the basic complaint here is that dropping of components and PS refresh takes some time, and this smells like a local variant of 71278 I will mark this defect as a dependent of it, and once it is fixed will revisit this.
The slowness in the UI is happening because of the propertysheet trying to populate itself with values from the remote VM. To see the difference, close the propertysheet view in ALL perspectives, open VE, close the propertysheet view again and start selecting - things are very snappy. For example, JLabel of Swing created some 40 JavaCommandStackPropertySheetEntry's which took some 40msec each, and hence a delay of 1.6sec. SWT's label had some 19 properties and only for 12 of which it went to the remotevm and hence didnt make an obvious impact. Trying to narrow down to where it was spending most time, I was able to go until BeanProxyAdapter#getBeanPropertyProxyValue(EStructuralFeature) - line 1438 - expression.invokeExpression(); Moving this to 1.2.
There is not doubt that we have to improve the lavish way the PS uses target VM information. But it makes me wander why will a Linux's loopback TCP/IP latency will be that much slower than that of Windows. Is there any configuration/environment setting that may impact this?
Under suse 9.2 with 1 gig of ram VE is so slow as to be useles. As soon as you close the properties window everything speeds up. I'm doing all my work with swing, so I'm not sure how that effects things
We have the same problem with: Fedora Core 4 Java 1.5 Update 5 Eclipse 3.1 VEP 1.1.0.1 VEP is very, very slow.
The same behavior is seen on Mac OS X... extremely slow performance that's dramaticly improved by closing the Properties View. Is there any sort of batch update process we could use to grab all the properties values at once, rather than make multiple calls to the remote vm for data? Also I seem to remember from a long time ago that property sheet values were queried multiple times for each selection change or update - does anyone know if this is still a problem?
I notice this is very slow too on this Dual Core AMD64 4200+, 2GB RAM... Observations :- * When VE is running, a fake version of the window you're editing is created in a separate VM process. * When you make a change to the UI (e.g. Set the text on a button) this change is immediatly reflected in this fake window but the time to update the VE version is about 1 second or more. * This doesn't happen on Windows.
*** Bug 148312 has been marked as a duplicate of this bug. ***
One year after reporting the bug, I tried VE again on Ubuntu, in my new Athlon 64 3800+ computer, 1GB RAM. And there's no way to make it run at least smoothly. To put it simple: VE is unusable to develop swing GUIs under Linux. Either I use Netbeans to develop GUI, or use Window$ and Eclipse+VE under it. Please, VE is the best tool for GUI design, make it work properly into linux.
