I'm bogged down at the moment, but when I get free time, I can
probably figure this out via -Dgwt.jjs.traceMethod on the client
bundle in question. Probably will have to wait a few days.


On Wed, Sep 12, 2012 at 4:04 PM, Daniel Kurka <kurka.dan...@gmail.com> wrote:
> Hi Ray, hi John,
>
> I haven`t had the time to track down why this got optimized in 2.4 but does 
> not in 2.5 anymore. We are seeing huge gains on many different mgwt apps with 
> GWT 2.5.
>
> @John
> With mobile browsers you get a lot of small inconsistencies across many 
> different places. I initially went ahead and build an interface with 
> different implementations and used deferred binding in the gwt.xml file.
> The problem was the amount of overhead you had to do for a simple one liner. 
> So I went ahead and used a Generator to build an interface that is based on a 
> property provider. The interface basically just returns true or false.
>
> All the stuff used to compile out in gwt 2.2 so we could do something like:
>
> if(MGWT.getIsDetection().isIphone()){
>         //do some small workaround
> }
>
> So right now we have a lot of places where we use those one liners to fix 
> things. (we also use a lot of deferred binding as well).
>
> @Ray
> I am really interested in knowing why this used to work and right now it 
> doesn't.
> I just went ahead and changed the code inside the client bundle to cache an 
> instance of OsDetection to get around the clinit.
>
> OsDetection detection = MGWT.getOsDetection();
>
>     if (detection.isAndroidPhone()) {
>       bundle = GWT.create(MGWTClientBundleBaseThemeAndroid.class);
>     }
>
>     if (detection.isAndroidTablet()) {
>       bundle = GWT.create(MGWTClientBundleBaseThemeAndroidTablet.class);
>     }
>
> This actually dropped code size of more than 29%. I think we got a lot of 
> places still being affected by this change, but at this point I can go 
> through the codebase and apply the workaround or even decide to bite some 
> bullets on more direct deferred binding. The thing I am still wondering about 
> what broke that we do see this problem now. I could offer some work time to 
> go and build every version between GWT 2.5rc1 and GWT 2.4 to get a better 
> feeling for what the actual commit is and if this is something we need to 
> look further?! What do you think?
>
> -Daniel
>
>
>
>
>
>
>
>
>
>
>
> Am 12.09.2012 um 00:03 schrieb Ray Cromwell <cromwell...@google.com>:
>
>> I finally tracked this down, it appears Android client bundles are not
>> being optimized out of the Iphone build, for example. This code:
>>
>> public MGWTThemeBaseThemeStandardImpl() {
>>
>>               if (MGWT.getOsDetection().isAndroidPhone()) {
>>                       bundle = 
>> GWT.create(MGWTClientBundleBaseThemeAndroid.class);
>>               }
>>
>>               if (MGWT.getOsDetection().isAndroidTablet()) {
>>                       bundle = 
>> GWT.create(MGWTClientBundleBaseThemeAndroidTablet.class);
>>               }
>>
>>               if (MGWT.getOsDetection().isIPhone()) {
>>                       if (MGWT.getOsDetection().isRetina()) {
>>                               bundle = 
>> GWT.create(MGWTClientBundleBaseThemeRetina.class);
>>                       } else {
>>                               bundle = 
>> GWT.create(MGWTClientBundleBaseThemeIPhone.class);
>>                       }
>>               }
>>
>>               if (MGWT.getOsDetection().isIPad()) {
>>                       if (MGWT.getOsDetection().isIPadRetina()) {
>>                               bundle = 
>> GWT.create(MGWTClientBundleBaseThemeIPadRetina.class);
>>                       } else {
>>                               bundle = 
>> GWT.create(MGWTClientBundleBaseThemeIPad.class);
>>                       }
>>
>>               }
>> ...
>> }
>>
>> on GWT 2.5 is optimized into:
>>
>> function MGWTThemeBaseThemeStandardImpl_0(){
>>  ($clinit_MGWT() , false) && (this.bundle = new
>> MGWTClientBundleBaseThemeAndroid_iphone_safari_default_InlineClientBundleGenerator_0);
>>  this.bundle = new
>> MGWTClientBundleBaseThemeIPhone_iphone_safari_default_InlineClientBundleGenerator_0;
>> }
>>
>> This is essentially if(false) { android bundle}
>>
>> I'm a little perplexed since the compiler has never really optimized
>> stuff like (clinit(), boolean) && blah, since it would need to hoist
>> the clinit() out of there which it doesn't do yet. I probably won't be
>> able to fix this for 2.5, but one workaround is to inline the
>> GWT.create(OsDetection) into the bundle theme and avoid calling MGWT
>> (which has a non-empty clinit)
>>
>>
>> On Sun, Jul 29, 2012 at 8:16 AM, Daniel Kurka <kurka.dan...@gmail.com> wrote:
>>> I didn't have the time yet to build a test case without mgwt put here is a
>>> very basic entry point.
>>>
>>> Compiled with GWT 2.4 its around 30k with GWT 2.5-rc its 45k (many styles
>>> not being removed):
>>>
>>> I have attached an entrypoint which can be run with the latest mgwt jar in
>>> the classpath:
>>> https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=com.googlecode.mgwt&a=mgwt&e=jar&v=LATEST
>>>
>>> <inherits name="com.googlecode.mgwt.MGWT" />
>>>
>>> Let me know if you need more input.
>>>
>>> -Daniel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2012/7/23 Daniel Kurka <kurka.dan...@gmail.com>
>>>>
>>>> We are not using any cell widgets (we wrote our own for mgwt, because the
>>>> current ones don work for mobile).
>>>>
>>>> I already have a good guess where this might be coming from. I'll try to
>>>> provide a decent test case for it (without mgwt dependencies).
>>>>
>>>> -Daniel
>>>>
>>>>
>>>>
>>>> 2012/7/23 Rajeev Dayal <rda...@google.com>
>>>>>
>>>>> Daniel mentioned that somehow the CSS for the blackberry permutation is
>>>>> ending up in the iPhone permutation. That can't just be a Cell Widget 
>>>>> issue.
>>>>>
>>>>>
>>>>> On Mon, Jul 23, 2012 at 12:24 AM, Ray Cromwell <cromwell...@google.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Are you using any Cell widgets by any chance?
>>>>>>
>>>>>> I've seen that the Mail sample and ShowCase sample both shrunk, but the
>>>>>> MobileWebApp sample increased in size. This leads me to believe it's not 
>>>>>> a
>>>>>> compilation issue, but something in the user library pulling in a lot of
>>>>>> extra code.
>>>>>>
>>>>>> --
>>>>>> 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
>>
>> --
>> 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

Reply via email to