Submitted by Anonymous on Sat, 08/18/2001 - 01:38. Developers
I have been looking for a way to improve the performance of one of my program`s XRT tables (namely when the table is initially loaded with records from the database). There was a time when this table only had to handle < 50 rows of data, but now it has to handle 500 to possibly several thousand rows. Currently the source calls XrtTblAddRows() for each record that is grabbed from the db. But now I`m wondering if it would be more beneficial to just create an XmNxrtTblCellValues structure of my own, dump the db records into it and slam the contents of this struct into the table. Would there be a noticable performance increase in doing this over the plain old multi calls to XrtTblAddRows()?
Also, I`ve noticed that there is serious lag time involved when trying to select a row in a large table (3000+ rocords). Upon clicking on the row it takes several seconds for that row to highlight. Any suggestions on how to improve the performance of this callback?
Thanks for any help on the above.
Greg
Adding too many rows in your table is going to consume a lot of resources. But why bother to add so many rows in this case. Keep in mind, the screen space is very limited. In most of the time, most of the rows will be hidden. A simple trick to improve performance I used in my experience was to create only as many rows as can be displayed (50 rows the most). The extra work involed here is you need to implement a user defined scrolling polic. When the scroll value changed, you update the row data using the preloaded list of rows in you whatever data structure. I think this will also improve the callback resposiveness since only a small number of rows will need to be browsed and refreshed.
I hope this work for you.
This is an excellent technique, which can also be applied to the XmList.
The real problem, though, is that the interface is too small for the amount of data being presented. People are very good at zipping through large amounts of information when it is arranged sensibly and when the jumps are big -- that is, a telephone book is a fine interface for looking up a number, because it allows large jumps right to "M" and then smaller jumps to "Mo", "Mot", and "Motif", for example.
But the XmList is missing the large-grain movements; the scrollbar isn`t sensitive enough. The XmNotebook`s tabs are somewhat better. Perhaps two nested XmLists would be better still, with the first, e.g., to choose the letter of the alphabet to browse through.
Thanks for the advice. This sounds like the obvious solution and I have begun to implement it. In the meantime however, I`ve had to seek out other avenues due to time constraints. Setting resources that control table calculation and re-draw have helped load a large table in 3-5 seconds (where it used to be 45+ seconds for the same number of records). Obviously these short-cuts will only help to a certain point as the table keeps increasing in size. Thanks again!
dbl,
Good point.
Thanks.