ZK3.0.4 Slow tree/listbox rendering

answered 2008-04-02 02:05:15 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: jebberwocky

Hello Ross

What is your testcase for the No.3?

answered 2008-04-07 05:58:22 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: morey_surfer

Sorry for the slow reply...

Our test case in no.3 is we have a ListModelList behind the listbox using a ListitemRenderer to render each item which can have 1 or more columns (user specifies this before the listmodel is constructed) which has a listcell each.
I usually test with around 4-6 columns as that is the usual expected for a user on our application. With 3.0.3, there is some delay with the load on demand rendering (up to a second for an entire page of rows to be rendered as you scroll down the page) but with 3.0.4 it take 2 or more seconds for the same operation.
All tests are in FF as IE is always slower.

We have also noticed that setVisible(true) does not work for a BorderLayout when called from an EventListener after we upgraded. We are listening for the onClientInfo event and using that to display the resized and fully loaded interface in one step. It can be fixed by calling invalidate() on the parent window after
setVisible(true) but that was not required in 3.0.3.

Any information/help in resolving this would be much appreciated as we would like to upgrade to 3.0.4 but cannot as it hurts performance on our application too much.

Thanks in advance for the help.

~Ross :)

answered 2008-04-08 15:29:19 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: docent666

Seconded, similar issue: Listbox has a dynamic content (not populated by listmodel but by adding listitem children explicitely) and the update event takes 12 seconds on 3.0.4+ instead of 1 on 3.0.3. On the server side most of the time is taken by the isAncestor method, but what is tragic is what happens on the client side
- Firefox uses 100% processor time trying to handle this call, and during that it complains at least 2 times that a page script is taking too long to finish.

answered 2008-04-09 03:35:20 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: jumperchen

Hi Ross,

Could you provide your test case for us test?

BTW,have you seen the New Feature of ZK 3.0.4?
- http://www.zkoss.org/smalltalks/zk3.0.4/
And in your test case, have you specified the fixedLayout property to be true, which take better performance at client side?
If you can provide as fast as you can, we are appreciated, because ZK 3.0.5 will be coming.
Thanks,
Jumper

answered 2008-04-09 05:09:16 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: devinder

Hi Jumper,

I too have experienced the same slowness. In my case I have a list with single column with 4 rows. In my case list box gets populated from a DB (get's it values from JPA's ResultList).
It works okay (I think) if i change it to mold="select".

So I reverted to 3.0.3.

regards

Devinder

answered 2008-04-09 07:00:44 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: morey_surfer

I have tried to produce a sample that will replicate the problem but no luck so far. When I get time I will try again, but I will try to rule out any of our other third party libraries (that supply the data to build our trees) first and will let you know. Every time we have updated our version of ZK, performance has improved, until now that is, so I'm sure there is something fishing going on in our code that was not intended by the ZK developers lol.

Cheers,

~Ross

answered 2008-04-09 08:58:32 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: jasonhao

Jumper,

Combobox has the bad performance too. I append about 100 comboitem into a combobox in the onOpen event. Using 3.0.3 it could be finished within 1 second, but with
3.0.4 it takes at least 4 seconds. I tried 0408 fresh build but no luck.

answered 2008-04-09 09:30:37 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: jumperchen

Hi Devinder,

Do you mean that the slowness is caused by client side or server side?

Could you provide a simple sample for us test?

Thanks,
Jumper

answered 2008-04-09 09:34:26 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: jumperchen

HI Biubiu,

Which browser do you test for?
Could you also provide an example?

Thanks,
Jumper

answered 2008-04-09 10:13:30 +0800

admin
18691 ● 1 ● 10 ● 130

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

By: docent666

Hi all,

some more clarification:
I have a listbox defined as follows:
<listbox id="lbox" width="700px" >
<listhead>
<listheader sort="auto" label="Type" width="100px"></listheader> <listheader sort="auto" width="600px"></listheader> </listhead> </listbox>

and a button that onClick will clean and then populate the listbox by creating listitem objects with two listcells . fixedLayout="true" on listbox doesn't change anything - and even if it did, it shouldn't work like this that its better because the old way of implementing stuff starts to suck :) The main speed problem is on the client size - although a number of server-side 'isAncestor' calls for a listbox with 100 elements reaches 1.7 million...

Cheers,
Lukasz