Kbase P18252: Treeview performance seriously affected by number of dynamic
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
29/01/2003 |
|
Status: Unverified
FACT(s) (Environment):
Dynamics 2.0A
SYMPTOM(s):
Treeview is too slow
Many dynamic combo and lookup in dependent window
CAUSE:
Known issue. Problem is that a treeviewer operates with the following way:
a) It recreates the launched dependent window each time a different node type is selected (for instance order node => orderline node)
=> This requires a long time depending on the complexity of the viewers
b) Keeps the previous dependent window when the new selected node is of same type (order #2 node => order #3 node)
=> This is much more faster, only need to display new data
On their typical viewer, they have 8 dyn combos and 3 dyn lookups, which manage very static data most of the time.7 The construction & initialization & poputation of data in such a viewer already takes about 5 s on a fast machine (P4 1.8GHz). On an average machine, it really kills the application.
We have noticed that the performance is correct when these combos and lookups are removed.
We have also noticed that the problem is not really about fetching the data on the server to populate the combo, but mainly because of the necessary time to build and initialize all these dyn combos and lookups.
Suggested to redesign their key viewers by replacing the dyn combos by simple static combos with a cached list of items (especially for very static data). The main point is to achieve something that can directly access the combo widget without a smart object stack like adm2/dyncombo.w + adm2/combo.p + adm2/field.p + adm2/visual.p and adm2/smart.p.
Jan Van Lishout is currently thinking about designing a kind of cache manager to achieve that.
CAUSE:
BUG# 20030205-001
FIX:
Upgrade to Dynamics V2.0 Service Pack 02