A big tree renders many times faster, and is not rendered twice (refs #137) 4476cdbb0443

- **Rendering a big tree is many times faster, and clone, pull, switch and `oxy workspace add` stop rendering it twice (#137).** Measured on the VS Code history's depth-0 clone (19,545 files, 166,425 changes), `oxy workspace add` took 467 s on Earth and 176 s on an 8-core workstation, 11 GB at its peak; it now takes 7.5 s and 1.8 GB on the workstation. Three causes: (1) whether one change depends on another, which rendering asks about every deleted line, was answered by a depth-first walk that compared a change with the one sought only on coming back up to it, so it went through thousands of changes first although the answer is nearly always a direct dependency (spec §8.1): 262,678 questions took 4.4 billion steps and 838 CPU-seconds, and now take 5 CPU-seconds, with the same answers; (2) finding the subrepos rendered every file of the tree, after every clone, pull, switch and `workspace add`, where reading the tree and the subrepos' pins is enough; (3) a new workspace started on the target state with an empty directory, so the checkout's first snapshot found the whole tree deleted and rendered it to say so. `OXY_TIMINGS=1` now also says how a checkout's files were ordered (`graph: single order`…) and how its blobs were read.

        // How the files rendered: which way each graph was ordered, summed

        // over every core (`OXY_TIMINGS`).

        crate::timing::report_totals();

        let t = crate::timing::phase("blobs: get_many blobs");

        let got_all = self.store.get_many(refs);

        drop(t);

        for (r, got) in refs.iter().zip(got_all) {

        let t = crate::timing::phase("blobs: get_many chunks");

        drop(t);

        if crate::timing::enabled() {

            eprintln!(

                "timing blobs: {} blobs, {} chunks, {} one by one",

                refs.len(),

                chunk_refs.len(),

                blobs.iter().filter(|b| b.is_none()).count()

            );

        }

        // The tree and the subrepos' pins only: a materialized state

        // rendered every file of the tree to find them, after each clone,

        // pull, switch and `workspace add` (in the VS Code history, ~70 s

        // and 11 GB; oxygen#137).

        let mut state = self.load_state_indexed(&wc.deps)?;

        let tree = self.tree_view(&mut state)?;

        for (path, e) in tree.entries.iter() {

            if e.kind != NodeKind::Subrepo {

            let Some(b) = state.live_blobs(&e.node).first().copied() else {

            let pin = Pin::decode(&self.read_blob(&b)?)?;

            if tree.entries.contains_key(path) {

    let ops = repo.op_log().unwrap().len();

    assert_eq!(

        ws.op_log().unwrap().len(),

        ops + 2,

        "the add and its checkout, and no snapshot finding the tree deleted (oxygen#137)"

    );

        // On nothing, as the directory is, until the checkout: on `heads`,

        // the checkout's first snapshot found every file of the tree

        // deleted, rendering the whole tree to say so (195 s of a 467 s

        // `oxy workspace add` in the VS Code history, oxygen#137).

        let wc = self.new_working_copy(Vec::new(), "");

        // A dependency is looked for as it is found, before the walk goes

        // below it: most questions are about a direct one (spec §8.1 makes

        // a deletion depend on the inserter of the line after it, which is

        // what a render asks about), and a depth-first walk that only

        // looked when it came back up went through thousands of changes

        // first (oxygen#137: 4.4 billion steps rendering the VS Code tree).

        if stack.contains(b) {

            return true;

        }

                if m.deps.contains(b) {

                    return true;

                }