Async Tree: Create a fast path for children that resolve sync

[JacksonKearl]

Ref #140883

In my testing a folder with 50k nested files (touch {1..10000}.{js,map,ts,d.ts,jsx}) would render in ~3s with nesting off and 15s with it on. Profiling showed the bulk of this overhead was in creating/cancelling a ton of different timeouts for "slow element" states, and general Promise handling logic.

In the nesting case the children are known synchronously so all the Promise/timeout overhead is not needed. 079a688 creates a fast path for this case in explorer land to get the render time down to 10s, this PR extends that fast path into AsyncTree land to bring render time down to 5s.

[joaomoreno]

Very cool! 👏

5s is still quite a bit of time. How can we bring it further down?

[JacksonKearl]

Hm... so the breakdown is roughly:

• 1s for the file service to stat the directory with resolveChildren enabled (so it stats all 50k children too),
• 200ms for the explorer model to be created,
• 400ms for nesting to be computed,
• 2s in the asyncTree's doRefreshSubTree (the sync fast path here could be extended upwards to this call in theory)
• 750ms in asyncTree's refreshAndRenderNode, largely in filtering and the URI/string manipulation needed to do so

Easiest win is probably extending this optimization up to doRefreshSubTree. Next is maybe toFileStat (cc @bpasero), but there's nothing obvious going on that would be slow there. ls ing the files takes half a second already.

In terms of big scale architectural changes I think streaming the directory contents would be the solution, but that's a whole can of worms.

[bpasero]

If there is a costly operation in the file service that is under our control then I can look at it. Btw node.js recently added fs.opendir to stream the contents:

https://nodejs.org/docs/v14.16.0/api/fs.html#fs_fs_opendir_path_options_callback

But this is not really exposed through our file services...