Recent

Author Topic: [Solved] ShellTreeView Node Expand: why second expand is slower than first one?  (Read 665 times)

d7_2_laz

  • Sr. Member
  • ****
  • Posts: 323
Quote
What's strange is that deletion of the child nodes in the C:\Windows\WinSxS subtree takes much longer than adding them...
(with option 1, previous behaviour, for to assure)
Yes, i saw that yesterday evening too. What i find strange: when retrying it now again, there is no delay at collopse (option 1). Sometimes yes, sometimes no? Hmm
Will try some more retests about that (especially collapse) this evening

But regarding the original topic, i think this could be marked as solved later.

wp

  • Hero Member
  • *****
  • Posts: 10462
Quote
What's strange is that deletion of the child nodes in the C:\Windows\WinSxS subtree takes much longer than adding them...
(with option 1, previous behaviour, for to assure)
Yes, i saw that yesterday evening too. What i find strange: when retrying it now again, there is no delay at collopse (option 1). Sometimes yes, sometimes no? Hmm
Will try some more retests about that (especially collapse) this evening
I think there is some caching on the OS side...

When I repeat expanding and collapsing of WinSxS several times I usually (but not always) observe that
- option 1 expansion is fast at the first time, but slow subsequently
- option 2 is always fast in both cases
- option 3 is always slow in collapasing.
(felt times, not the times displayed).

I 'd interpret the difference between option 1 and 3 such that expansion by itself is always fast, but deletion is slow since it is involved in both cases (Node.DeleteChildren). In option 1, the expanded subtree is deleted before it is expanded again - therefore expansion is slow from the second time on. In option 3, the subtree is always deleted, therefore, it is always slow in collapsing.

d7_2_laz

  • Sr. Member
  • ****
  • Posts: 323
Tested again especially with regard to the “delay at collapse”, option 2 and 3

- Option 2 (keep childs, not clear them at expand)

Didn't encounter any(more) delay at collapse. Having tried various scenarios and different action sequences.

- Option 3 (clear collapsing nodes):

Yes,.the discrepancy between felt time for expand (short !) vs. collapse (long !) appears strange.
This differs surprisingly from the measured real times. Eg:  for expand: 0,106s, for collapse 0,049s, which is faster.
 
This small number measured within "TForm1.ShellTreeView1Collapsed" would look like as if the processing itself is fast, but its gui display simply is deferred by some reasons!

On the other hand, this procedure (ShellTreeView1Collapsed) is really reached very late (seen by setting  a breakpoint herein).
If we look in ShellCtrls TCustomShellTreeView.Collapse, apparently there's a lot of time spent for Node.DeleteChildren.
Which appears to me to take much longer as when being called from within option 1. May this be? Mysterious so far.
A next step could be to measure the runtime Node.DeleteChildren takes when being called from within option 1 vs. when from option 3. Do the numbers match?  And do they match somehow the 0,049s as reported from the main form?
 
-------------
   
Quote
In option 1, the expanded subtree is deleted before it is expanded again - therefore expansion is slow from the second time on 

Absolutely. Same opimion. Option 1; in a first expand, there's nothing to delete. In subsequent expands, there might be masses to delete. So they are longer by principle. This explains the question asked in the title of this topic.

d7_2_laz

  • Sr. Member
  • ****
  • Posts: 323
Here some numbers about "DeleteChildren" just for info.
The numbers are measured with GetTickCount and imo much more near to the real visual experience.

Option 1, seccond run:  "DeleteChildren" takes:     // the first open won't have anything to delete
  1,282 ms

Option 3:  "DeleteChildren" takes:
  2,500 ms
zhr second and subsequent runs: 1,281 ms

Does mean:  "DeleteChildren" takes (for "WinSxS") when using for option 1 vs. for option 3 each approx. 1,3 secs.
But for option 3, when the node is collapsed the first time,  that will take twice as long.

Remark: personally for me option 3 is out of interest (option 2 would be my favorite).
But i could very well imagine a good use case for it, eg. a treeview action "Collapse all" resp. "Compact tree",
where under the hood the whole memory of opened node is freed.



Code: Pascal  [Select][+][-]
  1. function TCustomShellTreeView.CanExpand(Node: TTreeNode): Boolean;
  2. .........
  3.       ecmRefreshedExpanding:
  4.         begin
  5.  Tick := GetTickCount;
  6.           Node.DeleteChildren;
  7.  Tick := GetTickCount - Tick;
  8.  Outputdebugstring(pchar('CanExpand delete children took:  ' + Node.Text + '   ' + Inttostr(tick) + ' ms' ));
  9.  ...
  10.  
  11. procedure TCustomShellTreeView.Collapse(Node: TTreeNode);
  12. .........
  13.   if ExpandCollapseMode = ecmCollapseAndClear then
  14.   begin
  15. Tick := GetTickCount;
  16.     BeginUpdate;
  17.     try
  18.       hadChildren := Node.HasChildren;
  19.       Node.DeleteChildren;
  20.       Node.HasChildren := hadChildren;
  21.     finally
  22.       EndUpdate;
  23. Tick := GetTickCount - Tick;
  24. Outputdebugstring(pchar('Collapse delete children took:  ' + Node.Text + '   ' + Inttostr(tick) + ' ms' ));
  25.  ...


 

TinyPortal © 2005-2018