RE: [Webunitproj-users] major performance issue with large selectlist

[Brian K. <bt...@ne...>]

We have been considering the idea of refactoring our large select boxes =
to a search/select component for a while now, but currently the pages =
load just fine, even over a WAN.  I guess the webunit performance issue =
will help push us towards investing the time/resources to make the =
changes.  And I agree with you - in the long run moving away from super =
large select lists in the UI is a good thing to do.

Thanks for the info and advice...

Brian

-----Original Message-----
From: Doron [mailto:dg...@sh...]=20
Sent: Friday, May 23, 2003 7:54 AM
To: Brian Knorr
Cc: web...@li...; Jake Dempsey
Subject: Re: [Webunitproj-users] major performance issue with large =
selectlist

Hi Brian,

	I understand your issue. In general I would say that 8K choices in a
drop down is usually not a good UI thing to do because eventually it
wont scale and it will be slow going over a WAN. I would suggest to redo
this so you have a filter to reduce the list size.

On Thu, 2003-05-22 at 18:34, Brian Knorr wrote:
> In our application we have select boxes (drop-downs) with over 8000
> options.  The IE browser comes up instantaneously, but webunit is
> tremendously slow. =20
>=20
> =20
>=20
> At first we didn=FFt know what the performance issue was, but =
suspected
> it was due to the 8000+ options.  So we ended up creating a simple
> html page with a single select box containing 8500 options.  With this
> we tested webunit and found the following time statistics:
>=20
> =20
>=20
> 1) Retrieving the WebResponse with WebClient.getCurrentState()  took 9
> seconds
> ->> This requires IE to transfer all the HTML to webunit and then for
> webunit to parse the HTML to create its own DOM tree since getting the
> DOM tree directly from IE is way too slow.

> 2) Getting a handle to the WebSelectField with
> WebResponse.getRootTag.findFirst() took 18 seconds
->> Webunit does a linear search of the XML DOM tree generated in the
above step. It should still not take that long so its possible that
parsing takes place at this point. If you put a profiler on web unit,
you'll be able to tell.
>=20
> 3) Setting the value of the select box with
> WebSelectField.setSelectOption() took 3 seconds
->> The reason for this is that web unit tries to find the option tag in
the IE DOM. This DOM is slightly different then the one Web Unit has and
searching the IE DOM for the right element takes some time.
>=20
> =20
>=20
> As you can see it=FFs taking about 30 seconds to set a single select
> box.  Any ideas why this might be taking so long?  This is becoming a
> showstopper for us -- any ideas on when a fix could be produced?=20
> Please advise.
->> So the question is, can this be improved with IE? I don't see
anything obvious to fix in Web Unit. You could get through this by
reducing the list size in your select box and this is probably better
GUI as well.

>=20
> =20
>=20
> Thanks,
>=20
> =20
>=20
> Brian=20
>=20
> =20
>=20
> =20