My Ultracombo is bound to a query that has 4000 records (stress testing ... trying to sort by groups etc)
to read these records using a :open-query, loop etc takes 200ms
to instantiate a form with the ultracombo bound to this query takes 30 seconds .. this is on a quad-core 2.66 with 8GB ram
My Ultracombo is bound to a query that has 4000
records (stress testing ... trying to sort by groups
etc)
to read these records using a :open-query, loop etc
takes 200ms
to instantiate a form with the ultracombo bound to
this query takes 30 seconds .. this is on a quad-core
2.66 with 8GB ram
Is that 30 secs just to do the binding? (ie NEW PBS() or Handle = QryHdl)?
-- peter
it's strange, the delay is when the screen "shows", i.e after the CONSTRUCTOR of the form hosting the control
it's nothing to do with db access either, I pumped all the records into a temp-table, and the time went down to 27 seconds ..
So, is it between getting the data into the table on the ABL side and having the populated control showing up? I.e., traffic jam on the Bridge?
certainly seems that way
We had a thread a while back on that topic which lead to the batching example. One wonders about the desirability of 4000 records in a browse.
yeah, still doesn't explain why it is soooo slow.
As for the number of records, I need to choose a "client" from a group of clients. There are 200+ client groups, each with a potential 200+ clients in.
I can create a separate combo for the group, and based on that refill the client combo, but I wanted to be able to drag and sort the client group from within the control itself.
Batching is possibly the way to go, but it seems such a backwards step (with all the code involved)
Batching is possibly the way to go, but it seems such
a backwards step (with all the code involved)
I believe the amount of code for batching is a fair price for the result
based on that refill the client combo, but I wanted
to be able to drag and sort the client group from
within the control itself.
Batching won't help you anymore once you enable all the fancy features of the UltraGrid. When then control starts to group by, sort or filter it requires all rows anyway.
Your example may identify a performance issue, but IMHO is not relevant.
First of all on the combo side :
1) One should not use simple combos when displaying list of more than 100/200 records. Because combos populate all items and because navigation is basic on combos.
2) When dealing with list of more than a hundred items, one should consider using lookups (dialog with filter/search capabilities and where batching between Server and Client is turned on).
Finally, this does not suppose that there is no problem of performance on the new architecture involving .Net infragistics component.
The bench to be accurate should compare "similar" component with the same size of data managed. For eg. adm2 browse with SDO and IG datagrid with databinding over PDS.
Your example may identify a performance issue, but
IMHO is not relevant.
I respectively disagree.
The same control using the same data from a dataset in vb or c# is a lot faster.
First of all on the combo side :
1) One should not use simple combos when displaying
list of more than 100/200 records. Because combos
populate all items and because navigation is basic on
combos.
Not a Ultracombo : you have filters, sorting, grouping all built into the control. That's why I wanted to use it.
2) When dealing with list of more than a hundred
items, one should consider using lookups (dialog with
filter/search capabilities and where batching between
Server and Client is turned on).
That's what I was using the ultracombo for
Finally, this does not suppose that there is no
problem of performance on the new architecture
involving .Net infragistics component.
The bench to be accurate should compare "similar"
component with the same size of data managed. For eg.
adm2 browse with SDO and IG datagrid with databinding
over PDS.
we don't use adm so I can't comment. But to populate a combo-box with 4000 items (clientgroup + client name) in the ABL takes 375 milliseconds. Not even a second.
A slightly longer time to populate the ultracombo I could perhaps understand. But over a 100 times slower ?
> Not a Ultracombo : you have filters, sorting, grouping all built into the control. That's why I wanted to use it.
I thought so as well, but now that we try it it does not support grouping nor multiple tables and no filter row either.
Have you had any succes using the Ultracombo for large numbers of records?
We eventually got round the problem by creating a dynamic-temp-table, populating that from the db table and then binding the temp-table as a datasource to the combo. About 10x faster than assiging the table directly to the combo. I have to confess that we have not revisited since 10.2A01 has been released. Misy do that.
Hi, I think a bug has been logged regarding the slowness of ABL on this particular situation. It may have been corrected inside pack 01. Have a check.
I should be able to check that this weekend. I've installed SP1, so I'll change my workaround back to the original version and see what difference the SP makes
Hi, my ultracombo has the same performance problem.
I've got 20000 records and the load of my combo is extremely slow.
I read about using a dynamic temp-table ?
I'm using 102B
Thx.