solution in the particular case. The thing is that all the client code
is loaded on startup the only thing that happens when user changes
pages is that new DTOs are sent over and the existing views (which are
already present on client) are rendered anew to reflect new data. This
rendering and attaching views to panels and to each other takes so
much time.
I have peeked into Google Wave html code. It's very clean and uses
mostly divs, sparsely tables. I wonder what they are using to layout
data: HorizontalPanel, HTMLPanel, Cell Layout, etc? As far as I know
client code is of the moment not open sourced.
On 12 Okt., 10:11, Jin <jintl...@gmail.com> wrote:
> Denis,
>
> Not sure if you're already aware of this or whether it will help your
> situation: There is a technique called code splitting where you split
> up a GWT app into smaller components so that the visible components
> load faster.
>
> Other components are loaded as needed or in the background after
> visible components have been loaded.
>
> http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html
>
> Haven't tried it, but sounds promising.
>
> Cheers,
>
> Jin
>
> On Oct 12, 9:01 am, "Armishev, Sergey" <sarmis...@idirect.net> wrote:
>
> > I am not specifically developing for mobile device (I am doing Network Management) and not consider myself guru in the mobile Web apps. But I did pretty good testing regarding performance of my GWT apps on mobile devices to allow our customers use their smart phones for network management. What I found that performance greatly depends on performance of Javascript engine running inside mobile browser. On my Android my alarm management app was running probably with the same performance as on my desktop. No visible performance degradation. On Windows Mobile 6.5 with default "Pocket Explorer" browser my app was just frozen! Only after installing Opera browser it started to run without visible performance problems. Just to let you know that I am using long polling to achieve real time visualization and operators can exchange instant messaging through the same GWT RPC calls.
> > I can recommend to test your app on Android first to see the best performance and then go to other mobile devices
>
> > -Sergey
>
> > -----Original Message-----From:google-web-toolkit@googlegroups.com[mailto:google-web-toolkit@googlegroups.com]On Behalf Of denis56
> > Sent: Monday, October 11, 2010 4:44 PM
> > To: Google Web Toolkit
> > Subject: Re: Recommendations for improving performance of a mobile application
>
> > Hi,
>
> > We already do that. Only changed objects are sent over the wire. There
> > is of course question of granularity, but i think we have struck a
> > good balance between complexity and efficiency. Are you also
> > developing for mobile?
>
> > On 11 Okt., 22:01, "Armishev, Sergey" <sarmis...@idirect.net> wrote:
> > > Regarding slow RPC calls. Just try to send incremental data changes,
> > > only the data that been changed/added/deleted and cache main data on
> > > client. You might have thousands of items but only few of them or
> > > nothing been changed between RPC calls. I usually send full update when
> > > number of changes exceeds certain critical level when cost of update is
> > > higher then full update. Another hint is to change only data that
> > > visible to user. Usually there are not much visible data particularly on
> > > mobile device.
>
> > > -Sergey
>
> > > -----Original Message-----> From:google-web-toolkit@googlegroups.com
>
> > > [mailto:google-web-toolkit@googlegroups.com]On Behalf Of denis56
> > > Sent: Monday, October 11, 2010 2:27 PM
> > > To: Google Web Toolkit
> > > Subject: Recommendations for improving performance of a mobile
> > > application
>
> > > Hello to everyone,
>
> > > We decided to give it a try programming a mobile application with GWT
> > > - frequent RPC updates, very component-oriented and frequently
> > > changing data. At the moment we try to meet bearable performance
> > > benchmarks since current performance is so dismal. To change to a
> > > different page (fully dynamic) takes more than a minute at times ;
> > > ( Clicking on clickable panels, which are present in large quantities
> > > on every page, is also excruciatingly slow.
>
> > > I have watched videos from Google I/O Conference 2010 (Architecting
> > > for performance with GWT, GWT's UI overhaul, Faster apps faster) and
> > > tried replacing some of the widgets with UiBinder. This had so far
> > > brought only minimal performance improvements. There are some critical
> > > observations I would like to share and maybe you would have valuable
> > > suggestions
>
> > > * One of the things Joel Webber tells is that widgets are slow.
> > > Unfortunately everything is a widget in our app: clickable panels for
> > > selection and HTMLPanels/FlowPanels to layout clickables. There is
> > > very little space to cut off on widget. What would be the most
> > > lightweight component to implement onMouseDown-Event (a Button or
> > > clickable FlowPanel)? Is it worth the effort to replace all HTMLPanel/
> > > FlowPanel possible with new Cell Widgets (I am thinking about CellList
> > > in particular). Are they plain faster for layouting components?
>
> > > * Running Firebug Profiler and Speedtracer shows that PRC requests
> > > take the most time. On page change, for example, an PRC call would
> > > return a rather big list of DTOs - they have hierarchical logical
> > > structure - and each is then injected into corresponding view that
> > > attaches itself to parent view for display. So profiler says that
> > > add()-calls take the most time. But I can hardly imagine a way to get
> > > rid of these add calls because the views have to be attached to the
> > > owning views. Is there a better strategy to display lists of lists of
> > > data?
>
> > > * We use tables for layouting and in the process of converting that
> > > into divs, as well as converting syles to eliminate style chaining.
> > > Could that improve performance of mobile browsers significantly? One
> > > of the insights Speedracer gave is that parsing HTML and recalculating
> > > CSS styles takes a whole lot of time.
>
> > > Would really appreciate every suggestion. Thanks,
> > > Denis
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Google Web Toolkit" group.
> > > To post to this group, send email to>google-web-toolkit@googlegroups.com.
> > > To unsubscribe from this group, send email to>google-web-toolkit+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.
>
> > > </PRE><BR><span style='font-size:8.0pt;font-family:"Arial","sans-serif";color:#003366'>
> > > _____________________________________________________<BR>
> > > This electronic message and any files transmitted with it contains<BR>
> > > information from iDirect, which may be privileged, proprietary<BR>
> > > and/or confidential. It is intended solely for the use of the individual<BR>
> > > or entity to whom they are addressed. If you are not the original<BR>
> > > recipient or the person responsible for delivering the email to the<BR> intended recipient, be advised that you have received this email<BR>
> > > in error, and that any use, dissemination, forwarding, printing, or<BR> copying of this email is strictly prohibited. If you received this email<BR>
> > > in error, please delete it and immediately notify the sender.<BR>
> > > _____________________________________________________
> > > </SPAN><PRE>
>
> > --
> > You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.To post to this group, send email togoogle-web-tool...@googlegroups.com.To unsubscribe from this group, send email togoogle-web-toolkit+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.
>
> > </PRE><BR><span style='font-size:8.0pt;font-family:"Arial","sans-serif";color:#003366'>
> > _____________________________________________________<BR>
> > This electronic message and any files transmitted with it contains<BR>
> > information from iDirect, which may be privileged, proprietary<BR>
> > and/or confidential. It is intended solely for the use of the individual<BR>
> > or entity to whom they are addressed. If you are not the original<BR>
> > recipient or the person responsible for delivering the email to the<BR> intended recipient, be advised that you have received this email<BR>
> > in error, and that any use, dissemination, forwarding, printing, or<BR> copying of this email is strictly prohibited. If you received this email<BR>
> > in error, please delete it and immediately notify the sender.<BR>
> > _____________________________________________________
> > </SPAN><PRE>
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment