Forum > LCL

[Solved] ShellTreeView Node Expand: why second expand is slower than first one?

(1/4) > >>

d7_2_laz:
Coincidentally seen (Win x64): open (eg. via the ShellView demo) a highly populated folder (eg. Windows\WinSxS).
Collapse it. Expand it again ... appears to be much slower than the first expand. Why?
Would have expected that the second expand runs instantly, as the node is already populated.
Why the node is populated each time? (I assume there is a reason)

Changed simply for testing CanExpand  with instant second expand:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---function TCustomShellTreeView.CanExpand(Node: TTreeNode): Boolean;var  OldAutoExpand: Boolean;begin  Result:=inherited CanExpand(Node);  if not Result then exit;  OldAutoExpand:=AutoExpand;  AutoExpand:=False;  BeginUpdate;  try    Result := True;    if Node.Count = 0 then begin     // Added simply for test        //Node.DeleteChildren;       //  Not becessary regarding the condition        Result := PopulateTreeNodeWithFiles(Node, GetPathFromNode(Node));    end    else  Result := True;           // Added    AutoExpand:=OldAutoExpand;  finally    EndUpdate;  end;end;

wp:
I had thought that child nodes would be destroyed when their parent is collapsed, in order to save memory load. But I cannot find anything related to "Collapse" in the ShellTreeView code - so, probably I am wrong, and your modification would be a solution.

On the other hand, why not implement that "Free-on-collapse" thing? Would there be a disadvantage in having it?

d7_2_laz:
Hi wp, i'm simply not yet deep enough inside the Shell tools for to understand
- why at all a population might be triggered by a CanExpand query
- and why at all nodes might be cleared or childs destroyed when a node is collapsed.
To my simple understanding maybe intuition a node collapsed is a potential candidate to be re-opened, so i never would clear it when being collapsed.
I assume there is a good reason to do so, but i don't know it. Simply missing of info on my side. What's the benefit to clear? Save memory? Never did run into a bottleneck here.

Beyond intuition, most other file tools i know about re-open (re-expand) nodes instantly and that wuld be my own expectation too.

A nice side-effect i could imagine is that a re-populated node will on-the-fly catch all modifications of the folder subtree needed from actions outside.
But imo that would be rather a question of how to deal with file change monitors.

I was simply really surprised that a subsequent expand takes (felt:) the doubled time of the first one (may be internally the population is done twice?).
The disadvantage of a "Free-on-collapse" in my eyes: why not keep information that is already there but destroy it? Would lead to much redundant work.

I don't think the nodes are cleared intentionally (eg. at collapse). It's simply that they are ckeared and re-built each time a node is re-opened again. (no memory save advantage could be seen here).

For to avoid misunderstanding: i feel the shell tools are excellent - that's why I want to use them more and more  for new things.

d7_2_laz:
I experimented a while using the change mentioned above (within CanExpand) and did not find any negative indication why it should not be applied.

So i did open a issue note on that:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40022

Supplementary remark: i'd expect that when selecting a subnode "Sub1" beyond parent node "Parent1", that when i collapse Parent1 by click on the expand sign, and re-expand it again, the previous selection marker on Sub1 is preserved.
Using the change, it stays preserved. By the current behaviour (= sub nodes cleanup) it goes lost. Not ok. Please keep my selection!

GetMem:
@d7_2_laz
From the bugreport:

--- Quote ---when re-expanding the node, this is done instantly without clearing/repopulating the node
No more node population is done again redundantly. And certainly not it should take twice the time.

I'd expect that an already populated node can be re-expanded instantly.

--- End quote ---
What if the collapsed node's children are physically deleted from the hard drive while the node is collapsed? Isn't the (re)read on expand intentional? I wouldn't call it redundant. Maybe you can introduce a new flag, when set to true,  the disk changes are ignored for an already loaded node. 

Navigation

[0] Message Index

[#] Next page

Go to full version