getMember/getMembers performance issue

[akhader]

Be sure your post includes:

Version 3.0:SmartClient Version: 8.2/LGPL Development Only (built 2011-12-05)

and

Version 3.1d:SNAPSHOT_v8.3d_2012-07-18/LGPL Development Only (built 2012-07-18)

2. browser(s) and version(s) involved
FF 13.0.1, IE9

6. sample code if applicable

HLayout hLayout= new HLayout();
		for(int i=0; i<10; i++) {
			hLayout.addMember(new Canvas());
		}
		
		long startTime = System.currentTimeMillis();
		
		for(int i=0; i<10; i++) {
			hLayout.getMember(i);
		}
		
		long endTime = System.currentTimeMillis();
		  System.out.println(""+ (endTime-startTime));

The result of the execution on:
FF 13.0.1:
3.1: 928
3.0: 18
IE 9:
3.1: 1178
3.0: 146

If we replace the for loop that get the Member
by:

hLayout.getMembers();

The time of the execution will be:
FF 13.0.1:
3.1: 512
3.0: 3
IE 9:
3.1: 946
3.0: 2

From the results above we can be sure that there is a performance issue in getMember and getMembers methods.

[chrylis]

Which version of the GWT SDK is this under? The update that came out on 2012-06-29 absolutely crushes performance (and I'm pretty sure that it's GWT's fault, since I didn't change the SmartGWT version, and it has a couple of similar issues with SmartGWT.mobile), but I haven't yet been able to try the version from 2012-08-08. Unfortunately, Google immediately yanks the old versions when it updates, so I wasn't able to talk Eclipse into downgrading to the May version.

[akhader]

The GWT version is 2.4
The Eclipse version is Indego

The above code is executed in the same version of GWT, and different version of SmartGWT, So I think it is a SmartGWT issue.

[chrylis]

The GWT version is 2.4
The Eclipse version is Indego

The above code is executed in the same version of GWT, and different version of SmartGWT, So I think it is a SmartGWT issue.

Which *build* of the GWT SDK? I didn't have the problem with 2012-05-something and did have it with 2012-06-29. (You can look this up in Help->About->Installation Details.)

[akhader]

The GWT SDK is 2.4.0

[chrylis]

Look for a version number like 2.4.0.v201208080120-rel-r37.

[akhader]

It happens on both version:
SDK 2.4.0 2.4.0.v201208080121-rel-r42
and
SDK 2.3.0.r37v201106211634

[Isomorphic]

getMember() was modified such that in some cases it makes a series of calls from JS to Java. This has no speed impact in compiled mode, but in development mode each of these calls is a network trip. This should go away with SuperDevMode in upcoming versions of GWT.

[chrylis]

getMember() was modified such that in some cases it makes a series of calls from JS to Java. This has no speed impact in compiled mode, but in development mode each of these calls is a network trip. This should go away with SuperDevMode in upcoming versions of GWT.

Given that Super Dev Mode is probably not going to be official until 2.6.0 at least, please see if there's a practical way to revert this change. These round trips cause calls to take seconds each on my development machine, which is a 2.4GHz+ Core i7. I rewrote some of our code to avoid calling these methods, but operations that should take milliseconds are still taking seconds, and it's killing our ability to develop interactively.

I am having the same issue and also had to try to avoid these calls because what was taking seconds to load a page is now taking over a minute. This creates an almost impossible debugging environment. We've work around some of it by keeping our own member cache and getting members from there, but we cannot avoid these calls completely and we shouldn't have to just so we can debug.

[Isomorphic]

We can't revert this change without dropping the very important feature that returned objects have the correct type, eg, if it's a ListGrid, you get a ListGrid, not a Canvas.

Are you running a setup where the Development mode client and server are on separate machines? Moving them to the same machine would made a big difference if so.

[chrylis]

No, both are on the same machine. After dev mode slowed down so much (I initially thought it had crashed), I profiled the Java process, and the GWT OOPHM runtime is spending tens of seconds per test launch encoding and decoding messages to and from the browser plugin. Any network overhead between the OOPHM host and plugin is trivial.

In my case they are also both on the same machine.