Inefficient way to create the first version of the dependencies tree after loading a project

[lifengl]

GroupedByTargetTreeViewProvider.BuildSubTreesAsync will create nodes by nodes and insert them to the tree. It turns out to be a very inefficient way to create the immutable tree. When the code add one item, the entire spine will need be replaced (also it remembers the each change in the history record). The main project tree in CPS has been written to create it from bottom-up. (Creating leaf nodes first then folders with existing children nodes). This will reduce lots of CPU/memory overhead. The later sequence still has to update node by node because of the limitation of the current data structure, but usually, it will do much less change after first iteration.

[Pilchie]

I'll try to take a look at this.

[abpiskunov]

Let me first check some thing with Lifeng. There was a reason i did it this way. When it was done other way tree nodes were collapsing when they were updated and tree looked jumping allthe time after DT builds.

[lifengl]

@abpiskunov came and told me that the tree actually was updated heavily during the loading time, which means that optimize the first load won't improve the overall perf much. In that case, it won't be worth to do the change. I agree that sounds a good explanation on why we saw a very big change history for our tree. Based on that, I agree fixing the first load doesn't make big sense, and we can punt this.

[drewnoakes]

I'm still familiarising myself with how the tree is built and updated, but from the above discussion I can't see any actionable idea here.

As I work through that part of the dependencies node and run more profiling I'll know more and revisit this.

[davkean]

When it was done other way tree nodes were collapsing when they were updated and tree looked jumping allthe time after DT builds.

I would expect that top level nodes should come from evaluation, design-time build data should only be graph nodes.

[Pilchie]

I think @nguerrera's hope and our plan before was that we would populate non-top level nodes directly from parsing the assets file instead of relying on MSBuild raising items for everyting. That would make design time builds faster, allow us to cache less design time build data, etc.