On Thu, Mar 4, 2010 at 3:17 PM, Matt Mastracci <matt...@mastracci.com>wrote:
> We use repeated calls to GWT.create() for dependency injection and to > generate code for our internal widget templating framework. Both of them > also use nested GWT.create() calls under the hood in generated code for > instantiating associated resources bundles. The gwt-rpc-plus framework also > uses a call to GWT.create() to initialize the appropriate transports for > every request. I can rework them to cache the results of GWT.create(), > although I don't believe many of them would ever end up with more than one > soft permutation always. The code was written under the assumption that the > compiler would elide the call to GWT.create() in most cases and replace > instance method calls with static ones (which still holds in most cases of > course). > > It probably won't have a great effect on our overall performance even if > some of the classes ended up with runtime switches in the output code, since > all of those calls aren't in performance-critical code. > Soft permutations already assumes you are willing to trade off some performance for reducing the number of permutations, so I don't think this should be that big a deal. Larger performance issues, which we can't do anything about, will come from the loss of de-virtualizing instance method invocations and the subsequent loss of inlining. > Type tightening could still be done ahead of time on the return value of > the JSNI method, couldn't it? The results of type tightening would always be > the tightest common superclass of all of the potential results. AFAICT, this > tightened return value should be statically computable from the list of > possible rebinds from the soft permutation since each of the types > potentially returned is guaranteed to be in the final output code. AFAIK, type tightening is never done in JSNI code. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
