[Laszlo-user] combo box bloat == 100 meg laszlo app

William Krick wkrick at eio-online.com
Fri Apr 7 10:20:00 EDT 2006


Jim,

In the example attached to LPP-1439, the comboboxes are supposed to cascade
refresh downward automatically when you select an item in any combobox.  To
get this to happen, I added code that extends textlistitem so that the
combobox selects the first item in the list when the data is loaded.  If the
standard combobox would select its own first item (and fire a select event)
when the data underneath it changes (or preferrably when it's done
changing), I wouldn't need to do that hack.

Now regarding why it doesn't work with a datacombobox...

When I attach a datacombobox to a static XML dataset, it appears to select
the first item automatically.  However, when it's attached to a dynamic
dataset via HTTP, it does not select the first item when the dataset is
loaded.  The first item selection and firing of a select event is critical
to the functionality of my example.

The problem is that you can drill down the list one combo at a time all the
way to the end, then if you go back to the top and pick a different year,
all the comboboxes below don't refresh and are not valid for that year.  The
entire set of displayed combobox values must be valid at all times.


Regarding the destruction of _cblist...

I just wanted to clarify that we are destroying the _cblist on the
*datacombobox*, not the standard combobox.  Also, I'm not sure that I
understand what you mean about destroying it in the ondata handler.  Whose
ondata handler are you talking about?

...
Bill




-----Original Message-----
From: Jim Grandy [mailto:jgrandy at laszlosystems.com]
Sent: Thursday, April 06, 2006 8:08 PM
To: Tim Patsch
Cc: Laszlo-User
Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app


Hey Tim,

I'm glad you are seeing performance improvements when you destroy the
cblist. I had written a post earlier today suggesting this, but
forget to hit send! Sorry. I think that if you destroyed the cblist
in your ondata handler, rather than whenever the popup closes, you'll
may have better luck. There are problems with managing selection w/o
a cblist in certain cases.

And you will have problems getting datacombobox to work for cascading
comboboxes -- this has been filed as LPP-1439.

I think working through these two issues is likely to be more
profitable than trying to change combobox to create its cblist on
demand (and destroy it at appropriate times).

jim

On Apr 6, 2006, at 3:38 PM, Tim Patsch wrote:

> Followed through on this.
>
> Am using a datacombobox in the automobile data benchmarking app and
> destroying the cblist (list of text items associated with each
> combo) at the
> close of the basedatacombobox.setOpen() method.   Only doing this
> for the
> dummy combos in the app though.  Can't seem to get the datacombobox
> working
> for the actual cascading automobile data combos.   One step at a
> time .
>
> Ran a test with 100 dummy combo boxes added.  This scenario would
> typically
> either bog the benchmarking app down completely or require minutes to
> complete previously.  It now comes in consistently under two seconds
> indicating that the texlistitems are the bloat.
>
> There's obviously a slight performance hit when opening each combo
> as it
> must hit the dataset for it's contents every time it's opened.
>
> We still need a better solution though.  We have linked combos in
> our app
> whereby the selection in one causes the contents of another to change.
> Need a workable solution there.
>
>
>
>         <method name="setOpen" args="open" ><![CDATA[
>             if (!this._initcomplete) {
>                 this.isopen = open;
>                 return;
>             }
>             if (open) { // open combox
>                 if (this.isopen) return; // tends to get called
> more than
> once
>
>                 LzModeManager.makeModal( this );
>
>                 this._setupcblist();
>
>                 this._cblist.bringToFront();
>                 this._cblist.setVisible(true);
>
>                 LzFocus.setFocus( this._cblist, false );
>
>                 this.isopen = true;
>                 if (this['onisopen']) this.onisopen.sendEvent(true);
>             } else { // close combox
>                 if (!this.isopen) return;
>                 LzModeManager.release( this );
>                 if (!this['isopen']) return;
>                 this._cblist.setVisible(false);
>                 this.isopen = false;
>                 if (this['onisopen']) this.onisopen.sendEvent(false);
>                 if ( LzFocus.getFocus() == this._cblist ) {
>                     if ( this.focusable ) {
>                         LzFocus.setFocus( this, false );
>                     }
>                 }
>
> 	<!--Here-->
>
>                 this._cblist.destroy();
>                 this._cblist = null;
>
>
>
>             }
>             ]]>
>         </method>
>
>
>
> -----Original Message-----
> From: Tim Patsch [mailto:tpatsch at eio-online.com]
> Sent: Thursday, April 06, 2006 3:26 PM
> To: Jim Grandy
> Cc: Laszlo-User
> Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app
>
>
> I concur with Bill.  All indications are that once a datacombobox is
> clicked, it's textitems list is built.  Disposing of the list once
> a value
> is selected would probably be a good place to start.  I've got the
> source
> here and would like to try.  Not sure where the pertinent code is.
> Looking
> now.  Pointers welcome.
>
> -----Original Message-----
> From: William Krick [mailto:wkrick at eio-online.com]
> Sent: Thursday, April 06, 2006 12:24 PM
> To: Jim Grandy
> Cc: Laszlo-User
> Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app
>
>
> Jim,
>
> I did some testing with Tim's app.
>
> With 60 standard comboboxes containing No/Yes, the test runs in 13.8
> seconds.
>
> With 60 datacomboboxes pointing at a dataset containing No/Yes, the
> test
> runs in 1.7 seconds.
>
> However, if I open each datacombobox one at a time and select "Yes"
> and
> re-run the test, it now takes about the same time as the standard
> combobox
> run.
>
> I assume that the data isn't loaded into the datacombobox until the
> user
> actually clicks on it the first time and this is what makes the
> initial load
> times faster.
>
> However, we still have the problem that total memory usage.  In our
> app,
> people will probably open almost every combobox and that will end
> up loading
> all the data, grinding the app to a halt.
>
> Would it be possible to change the datacombobox so that it
> *unloads* the
> data after the dropdown list closes?  I think this would really
> help a lot
> with our app's memory use, and probably other openlaszlo apps as well.
>
> ...
> Bill
>
>
>
> -----Original Message-----
> From: Jim Grandy [mailto:jgrandy at laszlosystems.com]
> Sent: Wednesday, April 05, 2006 6:30 PM
> To: William Krick
> Cc: Laszlo-User
> Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app
>
>
> Bill,
>
> I would start by trying datacombobox against a static data set. If
> that is still too slow, we'll need to take a look at what going on
> and how things might be sped up.
>
> jim
>
> On Apr 4, 2006, at 12:37 PM, William Krick wrote:
>
>> Jim,
>>
>> Since you seem to know your way around the combobox pretty well,
>> how would
>> you suggest I go about creating a dedicated non-editable "Yes/No"
>> control
>> that looks like a combobox but without all the unneeded bloat?
>>
>> There are a few other "boolean" type combo choices in our app like
>> Male/Female but Yes/No is the real bulk of the app.
>>
>> It's perfectly ok for the choices to be hardcoded to Yes and No.
>> If I need
>> a control for something else, I'll just make a copy and hardcode
>> the other
>> choices.
>>
>> Should I start with combobox, basecombobox, or baseformitem?  Or
>> maybe
>> something else entirely?
>>
>> I think it at least has to extend baseformitem because the controls
>> are part
>> of a form and we must be able to submit them.
>>
>> I'm new to creating OpenLaszlo components so any advice or
>> assistance you
>> can provide would be greatly appreciated.
>>
>> ...
>> Bill
>>
>>
>> -----Original Message-----
>> From: Jim Grandy [mailto:jgrandy at laszlosystems.com]
>> Sent: Thursday, March 23, 2006 6:48 PM
>> To: William Krick
>> Cc: Laszlo-User
>> Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app
>>
>>
>> datacombobox *is* newcombobox, just under a different name. The
>> correspondence is:
>>
>> incubator/newcombobox becomes base/basedatacombobox
>> incubator/lzcomombobox becomes lz/datacombobox
>>
>> The main cause of bloat and slow initialization with combobox is that
>> it creates a floatinglist instance when it is initialized. So all of
>> the comboboxes in your application will have an associated
>> floatinglist instance.
>>
>> We improved that in newcombobox to share a floatinglist between all
>> newcombobox instances using the same style. But this created bugs
>> with data binding and synchronization, so with datacombobox we
>> changed it so that each instance has its own floatinglist, but the
>> floatinglist is only instantiated when needed.
>>
>> This is still a bit fragile because newcombobox/datacombobox is
>> engineered to get its selection manager and data state from the
>> floatinglist -- selection and value have to be managed manually until
>> the floatinglist is created. There are improvements to be made there.
>>
>> Note that both newcombobox and datacombobox are entirely data-driven
>> (hence the name of the latter), so you can't supply the menu items
>> statically as you can with combobox.
>>
>> jim
>>
>>
>> On Mar 23, 2006, at 1:26 PM, William Krick wrote:
>>
>>> I'm working on an OpenLaszlo application that has a lot of controls
>>> for data
>>> input.
>>>
>>> When I load our app up in a browser and check the memory use for
>>> that
>>> browser instance in task manager, it's around 100 megs.
>>>
>>> Obviously this is WAY too large and something has to be done to
>>> bring the
>>> size down.
>>>
>>> After some digging, it appears that the majority of our apps memory
>>> use is
>>> due to combo boxes.  LOTS of comboboxes.
>>>
>>> The combobox is critical to our application so we need a solution
>>> that
>>> brings the memory use for comboboxes way down.
>>>
>>> Also, a side effect of this bloat is that anything that dynamically
>>> manipulates the contents of a combobox like adding or removing
>>> items, or
>>> refreshing the list when connected to a dataset, is unusably slow
>>> in our
>>> application.
>>>
>>> I know there was some work done on a "newcombobox" but it appears
>>> that that
>>> might have been abandoned in favor of the "datacombobox" which
>>> doesn't
>>> really address the bloat problem.
>>>
>>> Can anyone tell me what, if anything, can be done to remedy our
>>> situation?
>>>
>>> My co-worker is putting together and will post an example that
>>> specifically
>>> addresses the performance problems when manipulating comboboxes but
>>> I just
>>> wanted to query the list about a solution to the larger problem of
>>> application bloat due to comboboxes.
>>>
>>> Is it possible to strip down the combobox and/or textlistitem to
>>> make them
>>> less memory hungry?
>>>
>>> ...
>>> Krick
>>>
>>> _______________________________________________
>>> Laszlo-user mailing list
>>> Laszlo-user at openlaszlo.org
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>>
>>
>>
>> _______________________________________________
>> Laszlo-user mailing list
>> Laszlo-user at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>
>
>
> _______________________________________________
> Laszlo-user mailing list
> Laszlo-user at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date:
> 4/4/2006
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date:
> 4/4/2006
>
> _______________________________________________
> Laszlo-user mailing list
> Laszlo-user at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date:
> 4/4/2006
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date:
> 4/4/2006
>

_______________________________________________
Laszlo-user mailing list
Laszlo-user at openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-user




More information about the Laszlo-user mailing list