Re: [gwt-contrib] Re: Multiple leftover fragments with a tree of code split points?
Alan Leung of the GWT team is working on a partial fix for this, called Automatic Fragment Merging, it merges together fragments automatically in order to reduce the size of leftovers while increasing the size of the exclusive fragments (which in many cases are too small and should be bigger). If code X is in fragment A and B, but not C and D, then if we merge A and B, X becomes exclusive. This means # of split points != # fragments, so you could have 30 split points, but only 15 fragments. On Sun, Sep 25, 2011 at 11:38 AM, John Patterson jdpatter...@gmail.comwrote: I am also hitting this problem with the left overs fragment and Lex suggestion does not seem to help. I have split points A and B which both use GWT-RPC and so all the RPC code gets moved into the left overs fragment which adds 30Kb to its size. I've created a new split point C, in front of A and B but the RPC code remains in the leftovers fragment - not in C as Lex seems to suggest it should. Problem is that split points D, E etc don't use RPC at all but still haee to download all that code. Every new split point a add (one for every html page) adds a bit more to the left overs fragment and I see no way to control this. Does anyone have suggestions how to limit the size of this growing leftovers? Is any fix in the works? Thanks, John -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Multiple leftover fragments with a tree of code split points?
On 26/09/2011 14:11, Ray Cromwell wrote: Alan Leung of the GWT team is working on a partial fix for this, called Automatic Fragment Merging, it merges together fragments automatically in order to reduce the size of leftovers while increasing the size of the exclusive fragments (which in many cases are too small and should be bigger). If code X is in fragment A and B, but not C and D, then if we merge A and B, X becomes exclusive. This means # of split points != # fragments, so you could have 30 split points, but only 15 fragments. Thanks very much Ray for the info. I have another approach to try - I may replace all RPC code with a Command executor and restrict access to it behind a runAsync() so all RPC code is in the single split point (and thus not in the left overs) The problem with using RPC directly is that the actual plumbing code is auto-generated so I can't restrict its access to behind a split point. Would this work: create all RPC services in a factory class that can only be instantiated behind a runAsync(). Perhaps I could also break other classes out into such split point factories such as Calendar widgets (large size also). Have you, or anyone else used such an architecture to reduce the left over fragment? Any better suggestions? Thanks, John -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Multiple leftover fragments with a tree of code split points?
Great ! It was one of my main concern when runAsync was released, there is a discussion on that topic on Lex's blog in 2009 http://blog.lexspoon.org/2009/09/exclusively-live-code.html?showComment=1254499021340#c6923160152357980710 Do you know how those specific split points will be highlighted in SOYC reports ? Thanx Sami On Mon, Sep 26, 2011 at 9:11 AM, Ray Cromwell cromwell...@google.comwrote: Alan Leung of the GWT team is working on a partial fix for this, called Automatic Fragment Merging, it merges together fragments automatically in order to reduce the size of leftovers while increasing the size of the exclusive fragments (which in many cases are too small and should be bigger). If code X is in fragment A and B, but not C and D, then if we merge A and B, X becomes exclusive. This means # of split points != # fragments, so you could have 30 split points, but only 15 fragments. On Sun, Sep 25, 2011 at 11:38 AM, John Patterson jdpatter...@gmail.comwrote: I am also hitting this problem with the left overs fragment and Lex suggestion does not seem to help. I have split points A and B which both use GWT-RPC and so all the RPC code gets moved into the left overs fragment which adds 30Kb to its size. I've created a new split point C, in front of A and B but the RPC code remains in the leftovers fragment - not in C as Lex seems to suggest it should. Problem is that split points D, E etc don't use RPC at all but still haee to download all that code. Every new split point a add (one for every html page) adds a bit more to the left overs fragment and I see no way to control this. Does anyone have suggestions how to limit the size of this growing leftovers? Is any fix in the works? Thanks, John -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r10672 committed - Rolling back 24166710. It's broken on IE7/WinXP....
Revision: 10672
Author: rdcas...@google.com
Date: Mon Sep 26 13:26:56 2011
Log: Rolling back 24166710. It's broken on IE7/WinXP.
Review by: rj...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=10672
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/PotentialElement.java
/trunk/user/src/com/google/gwt/user/client/ui/RenderablePanel.java
===
--- /trunk/user/src/com/google/gwt/user/client/ui/PotentialElement.java Fri
Sep 23 05:24:04 2011
+++ /trunk/user/src/com/google/gwt/user/client/ui/PotentialElement.java Mon
Sep 26 13:26:56 2011
@@ -17,8 +17,6 @@
import com.google.gwt.core.client.JavaScriptObject;
import com.google.gwt.dom.client.Element;
-import com.google.gwt.dom.builder.shared.HtmlElementBuilder;
-import com.google.gwt.dom.builder.shared.HtmlBuilderFactory;
/**
* EXPERIMENTAL and subject to change. Do not use this in production code.
@@ -39,10 +37,6 @@
*/
public class PotentialElement extends Element {
- static {
-declareShim();
- }
-
public static PotentialElement as(Element e) {
assert isPotential(e);
return (PotentialElement) e;
@@ -64,34 +58,34 @@
* that is needed.
*/
public static native PotentialElement build(UIObject o, String tagName)
/*-{
-var el = new $wnd.GwtPotentialElementShim();
-el.tagName = tagName;
-el.__gwt_resolve =
@com.google.gwt.user.client.ui.PotentialElement::buildResolveCallback(Lcom/google/gwt/user/client/ui/UIObject;)(o);
-return
@com.google.gwt.dom.client.Element::as(Lcom/google/gwt/core/client/JavaScriptObject;)(el);
+return
@com.google.gwt.dom.client.Element::as(Lcom/google/gwt/core/client/JavaScriptObject;)({
+ className: '',
+ clientHeight: 0,
+ clientWidth: 0,
+ dir: '',
+ getAttribute: function(name, value) {
+return this[name];
+ },
+ href: '',
+ id: '',
+ lang: '',
+ // should be @com.google.gwt.dom.client.Node.ELEMENT_MODE, but the
compiler
+ // doesn't like that.
+ nodeType: 1,
+ removeAttribute: function(name, value) {
+this[name] = undefined;
+ },
+ setAttribute: function(name, value) {
+this[name] = value;
+ },
+ src: '',
+ style: {},
+ tagName: tagName,
+ __gwt_resolve:
@com.google.gwt.user.client.ui.PotentialElement::buildResolveCallback(Lcom/google/gwt/user/client/ui/UIObject;)(o),
+ title: ''
+});
}-*/;
- /**
- * Creates an {@link HtmlElementBuilder} instance inheriting all
attributes
- * set for the given PotentialElement.
- *
- * @param potentialElement assumed to be a PotentialElement, used as
basis for
- * the builder
- * @return a propertly configured {@link HtmlElementBuilder} instance
- */
- public static HtmlElementBuilder createBuilderFor(Element
potentialElement) {
-PotentialElement el = PotentialElement.as(potentialElement);
-HtmlElementBuilder builder = HtmlBuilderFactory.get().trustedCreate(
-el.getTagName());
-el.mergeInto(builder);
-return builder;
- }
-
- /**
- * Tests whether a given {@link JavaScriptObject} represents a
PotentialElement.
- *
- * @param o the {@link JavaScriptObject} to be tested
- * @return true if the given object is a PotentialElement instance
- */
public static native boolean isPotential(JavaScriptObject o) /*-{
try {
return (!!o) (!!o.__gwt_resolve);
@@ -123,35 +117,6 @@
throw A PotentialElement cannot be resolved twice.;
}-*/;
- private static final native void declareShim() /*-{
-var shim = function() {};
-shim.prototype = {
- className: '',
- clientHeight: 0,
- clientWidth: 0,
- dir: '',
- getAttribute: function(name, value) {
-return this[name];
- },
- href: '',
- id: '',
- lang: '',
- // should be @com.google.gwt.dom.client.Node.ELEMENT_MODE, but the
compiler
- // doesn't like that.
- nodeType: 1,
- removeAttribute: function(name, value) {
-this[name] = undefined;
- },
- setAttribute: function(name, value) {
-this[name] = value;
- },
- src: '',
- style: {},
- title: ''
-};
-$wnd.GwtPotentialElementShim = shim;
- }-*/;
-
protected PotentialElement() {
}
@@ -159,53 +124,6 @@
this.__gwt_resolve =
@com.google.gwt.user.client.ui.PotentialElement::buildResolveCallback(Lcom/google/gwt/user/client/ui/UIObject;)(resolver);
}-*/;
- /**
- * Copy only the fields that have actually changed from the values in
the shim
- * prototype. Do this by severing the __proto__ link, allowing us to
iterate
- * only on the fields set in this specific instance.
- */
- private native void mergeInto(HtmlElementBuilder builder) /*-{
-var savedProto = this.__proto__;
-var tagName = this.tagName;
-var gwtResolve = this.__gwt_resolve;
-var className = this.className;
-
-
