listmodel listbox(paging) performance

answered 2007-05-13 07:46:23 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4309568

By: zanyking


I think trying to display and send more then 50,000 Data in a listbox to user's browser is not a good idea. It will hard to display and cause bad performance in both server and browser side.

Because ZK maintains an abstractive object UI model in each HttpSession to serve each user, and this technology let server could fully recognize the meaning of user's any action.

That's "The Force" of ZK's simplicity.

Anyway, maybe you should try to describe your paging solution more clearly, or post your code to give us a way to manupolate your problem.

Large data display is always a complex issue, It brings "Leaky Abstraction"
to Simplicity.

answered 2007-05-13 13:05:15 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4309754

By: simon_massey


Putting 50000 objects into the desktop in the users httpsession is not a good idea. You should impliment pagenation in your application at the data access teir. Avoid pulling such a lot of data into your web teir and creating tens of thousands of objects that your users routinely ignore.

answered 2007-05-14 08:41:24 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4310653

By: benedikt79

First of all: Thanks for your answers and excuse me for misformulating my question.

Of course we only want to view about 30 objects in the listbox. We search in our database and pass the appropriate objects to the listbox.

Nevertheless, we would like to use the navigation(paging) part provided by zk-listbox to navigate through the pages. Thus zk would render the navigation-part for
> 50000 object. On interaction by the user we would load the appropriate
> 30
objects of the requested page from the database and pass them to the listbox.

We already tested and the rendering of the navigation-part (only!) would already take a long time.

answered 2007-05-17 08:39:06 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4316911

By: zanyking

Sorry for misunderstood your question.

But even in server side, rendering 50000 objects befor use is still not a good idea.
I think you should implement your ListModel using lazyloading strategy.

Demo code is somthing roughly like this:

<window title="Lazy Demo" border="normal">
<zscript>
ListModel lzset = new LazyLoadingListModel();
</zscript>
<listbox id="list" width="200px" rows="10" model="${lzset}">
<listhead>
<listheader label="Load on Demend" sort="auto"/>
</listhead>
</listbox>
</window>


The URL of interface API is shown bellow:
http://www.zkoss.org/javadoc/2.3.1/zul/org/zkoss/zul/ListModel.html

The key method is "getElementAt(int index)". while implementing this method, you should load data frame according to input index.

answered 2007-05-21 18:11:57 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4322979

By: bobik72

Hi,

i am a colleague of Benedikt who started this topic, we both pursue the goal of adapting Listbox to a large amount of data. Maybe I post little bit of source code to clear things up - here's our ListModel implementation (it has been lazy loading all the time):

public class TableListModel implements ListModel {
private final FormWindow win;
private final Log log = LogFactory.getLog(getClass());

TableListModel(FormWindow window) { //FormWindow extends org.zkoss.zul.Window and "owns" the data
win = window;
}

public void addListDataListener(ListDataListener arg0) {
}

public Object getElementAt(int index) {
log.debug("Get element at " + index);
if (index < win.getFirstPageRecordIndex()
|| index >= win.getFirstPageRecordIndex() + win.getPageSize()) {

//switch page when necessary
win.changePageSilent(index); // this loads another small (~20 items) page of business objects
}
return win.getResults().get(index % win.getPageSize());
}

public int getSize() {
return win.getTotalResultSize(); //note this returns the actual list size (about 50,000)
}

public void removeListDataListener(ListDataListener arg0) {
}

public FormWindow getWindow() {
return win;
}
}

Now even with this lazy loading implementation we observe lots of time lost in ZK framework itself: loading of a listbox which is backed by a live list of 50,000 objects (although only a page of 20 is loaded at any time) takes about 30 secs.

We assume the time is lost in Listbox.syncModel where the method newUnloadedItem gets called once for each logical record. This results in 50,000 executions "new Listitem()" which we believe is where our app spends all that precious time.

I also tried to implement the ListitemRendererExt interface to limit the huge number of object creations, but this did not succeed - it seems to make no sense to add the same Listitem object more than once to the Listbox.

I would be thankful for any suggestions on how to improve the performance.

Best regards,

Dusan

answered 2007-06-17 08:02:38 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4366560

By: henrichen

Listbox with ListModel will generate that many Listitems as specified in getSize().
What it lazy load is the contents of the Listitem (What you save are the Listcells inside a listitem) NOT the listitem itself.

So in your case, I will suggest using a separate Paging component to cooperate with a Listbox (default mold). When the end user select a page, in Paging's onPage event handler, you retrieve what you want to from the database and populate a new ListModel and then set the new ListModel into the Listbox. This will automatically refresh the Listbox.


/henri

answered 2007-07-17 13:46:40 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4416412

By: razvanp

Here is the live data sample, with some changes:

<window title="Live Data Demo" border="normal">
<zscript>
<![CDATA[
public void loadModel(int size) {
System.out.println("Prepare model for " + size + " elements.");
String[] data = new String[size];
for(int j=0; j != data.length; j++) {
data[j] = "option "+j;
}
System.out.println("Array created.");
ListModel strset = new SimpleListModel(data);
System.out.println("List model created.");
list1.setModel(strset);
System.out.println("List model set.");
}

public void onCreateList() {
loadModel(30);
}
]]>
</zscript>
<listbox id="list1" width="200px" mold="paging" onCreate="onCreateList()">
<listhead>
<listheader label="Load on Demand" sort="auto"/>
</listhead>
</listbox>
<button label="0 enties" onClick="loadModel(0)"/>
<button label="10000 enties" onClick="loadModel(10000)"/>
<button label="9999 enties" onClick="loadModel(9999)"/>
<button label="20000 enties" onClick="loadModel(20000)"/>
<button label="19999 enties" onClick="loadModel(19999)"/> </window>


Well, it would be expected that the data resides on the server. Building the data vector is no performance issue (the server's message console shows this).
If the list is paged and virtual, why is generated on the server side an empty list item for each entry, even if their value is not queried?
As you can test, clicking on the 10000 button takes first a lot of time. Then,
9999 works very fast, and again 10000 very fast too. It seems the server and the browser have together a problem when the amount of items in the list varies (increases and even decreases) a lot.
So I have some understanding questions:
- shouldn't the model always reside on the server?
- shouldn't the model data been loaded on demand, as the user scrolls?
- the concept of virtual lists is that the size of the data is huge, while the amount of visible data is small. Then, why iterating the entries on the server and on client side? This produces the performance issue described on the thread.
- for the default mold, even if the entries are not visible, an empty table cell is going to be created, in order the scroll to be consistent. Could you not simply replace these blocks of empty space with a bigger div entry? This would increase the performance of the client JavaScript.
- for the default mold, the data is loaded exactly until the end of the visible space. Why not creating an option to load like twice the screen content, so when the users scroll smoothly they won't notice the loading of the data.

The same issues I have noticed on the Grid control.

For the moment the proposed solution of custom paging seems also to work in my case. Still, a proper implementation of virtual List and Grid controls would save development time and improve user experience.

With kind regards,
Razvan Popovici