Re: Optimizing subjective performance accessing big celllists (kind of double buffering)

Hi Gautam,

well, unfortunately I didn't try. I focused in profiling and solving different parts of the application that were under optimized, as complexity of merging both activities was a little higher than initially expected. At the very end, we concluded that performance was acceptable once we got around 250ms in preprocessing (independently of the use case) and 250ms in rendering if we have <= 100 items. Prior to that, our preprocessing took longer because of not doing things incrementally and because of much complex objects than really needed. On the other hand, we couldn't lower the rendering time. A CellList of 1000 items takes time to be rendered (2 seconds more/less) but well, I guess rendering 1000 items will not be that common... who knows... 

So, as we couldn't lower rendering time, bearing in mind the loading of > 100 items is being done within the same activity/view (so we cannot optimize subjective view according to the initial post because we're in the same place), we finally decided to not implement Jens suggestion :( 

On Tuesday, December 8, 2015 at 8:09:44 PM UTC+1, gau...@ainosoft.com wrote:

any update on this Jordi ? Did you get any significant difference in performance ? 

On Sunday, November 29, 2015 at 12:47:40 AM UTC+2, Jordi G. March wrote:

OK Jens, thx a lot for your answer.

I just render last 10-50 based on the device "capabilities" (kind a tricky, but an iPhone 4 just shows 15 and an iPhone 6, for instance, shows 50) and then have a "load older" button too... But, even with 50, the final end user impression can be optimized.

OK for mapping both places to the same activity then. Will rearrange code and create helper classes for code maintainability... yes, of course we'll give it a try! ;)

Thx a lot.

Best,

Jordi

On Friday, November 27, 2015 at 2:08:19 PM UTC+1, Jens wrote:

I would say: Don't render all available messages at once. Just render the latest 30 message and if the user wants to see older ones the user has to tap a "load older" button or you just load them when scroll panel reaches the near top.

There is rarely a need to render everything up-front especially for messaging apps where conversations are rarely deleted by users and can become pretty long.

If you absolutely don't want that then you probably need to adjust your current mechanism of switching between group/contact list view and the messages view. You haven't said how you switch views, but I guess introducing a third actor that manage both group/contact and message view/presenters can solve your problem. For example if you use GWT Activity + Places you would map both ConversationsOverviewPlace and MessagesPlace to the same Activity. That Activity then manages your ConversationsOverviewActivity and MessagesActivity internally so you can do your own transition logic.

-- J.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.