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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > 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 >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-user > > > > _______________________________________________ > Laszlo-user mailing list > [email protected] > http://www.openlaszlo.org/mailman/listinfo/laszlo-user _______________________________________________ Laszlo-user mailing list [email protected] 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 [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
