Re: Huge data slowing down Celltable

[Juan Pablo Gardella]

Wow ! how many rows!!! In IE is very slow. Very rarely requirement, is better to generate an excel file. I think with GWT at now is impossible to do fast. I think you must generate a html file in server side and then displayed.

Juan

2011/6/7 Leela <rcle...@gmail.com>

Hi,

I'm using GWT 2.2. We have requirement to display huge data (around
8000 rows and  20 columns) in Celltable.
The celltable is placed within a ScrollPanel to scroll the data.  We
are not using pager.

Following javascript is displayed " Stop running this script? A script
on this page is causing Internet Explorer to run slowly. If it
continues to run, your computer may become unresponsive". When I click
on "Continue few times, finally the data is displayed. However when I
drag the scrollbar or click on the row, it is very slow.

We are using Firefox 3.5 and IE7. This slowness happens in both the
browsers.

Can celltable handle such huge data without pager? Any help/suggestion
appreciated.

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Leela]

[John LaBanca]

8000 rows is too many to display at once.  Even a HTML file probably take a while to load, and the scrollbars become almost unusable because you don't have the fidelity to narrow in on a row.  The slow script warning happens when you block the UI for too long (sometimes measured in seconds, other times in lines of execution).

You're better off using a pager, but if you really want to load 8,000 rows, you can break it into chunks.  CellTable uses a push API, which means you can push data in segments and they will be appeneded to the end.  The process would look like:

1. Send asynchronous request for 250 rows

2. On response, push 250 rows into CellTable

3. Go back to step 1

The above method has two advantages.  First, you only request 250 rows at a time, which means a faster RPC call and less time deserializing the response, so your startup time will be much faster.  Second, you only render 250 rows per event loop, so the browser doesn't lock up while populating the table.  The additional rows are appended to the end of the table.  You can play around with different row counts to get the best performance tradeoff.  You might even load 50 on the first call for max startup time, then switch to 500 to reduce the load on the sever.

Thanks,
John LaBanca
jlab...@google.com

[Alain Ekambi]

8000 rows ??? 

If  that s the requirement then maybe you should revisit the requirement instead of trying to implement something like displaying 8000 rows at once. Who is able to process 8000 rows of data  at once?  

2011/6/7 John LaBanca <jlab...@google.com>

--

GWT API for  non Java based platforms

http://code.google.com/p/gwt4air/

http://www.gwt4air.appspot.com/

[leela c]

Thanks for the suggestions.

8000 is the max limit for the data in our case. Though this is not a
practical scenario, we just thought of handling the worst case. We
wanted to identify if the problem was in our coding or if Celltable
has some issue with such large data.

As John suggested I would try the Push API approach else we might
require to revisit the requirement.

[federico]

are you sure that the bottleneck is the display of the data??

if you are making rpc calls to get the 8000 data to display the critical poit could be the rpc deserialization. try to create random data on the client to check this.

[Jacob Glusted Madsen]

I am having the same type of problem - fetching and displaying  huge amount of data via RPC (displayed in a celltable) runs extremly slow.

Our analysis indicates, that  it is the  serialization/deserialization that causes the problem.

The rendering of the celltable is actually extremly fast, at least if you are using a pager !!

 Any sugestions on how to make the serialization/deserialization run faster ??

[Jens]

 Any sugestions on how to make the serialization/deserialization run faster ??

Use pure JSON with overlay types (almost no overhead) and if its still too slow for you then you have to fetch your data in smaller chunks.

-- J.