logseq is unusably slow in a garden with ~3500 nodes (Markdown), in particular graph view

Nobody has claimed this yet.

**Describe the bug**
Logseq seems to struggle a lot with my garde, which has about 3.5k Markdown nodes; it takes very long to clone, then just hangs (and prompts 'kill it now' dialogs in Chromium) when trying to use graph view.
https://twitter.com/flancian/status/1400721725088731137

**To Reproduce**
Steps to reproduce the behavior:
1. Set up logseq with https://github.com/flancian/garden
2. Wait for several (>2) minutes while it clones/parses (this would be borderline fine if it were a one off setup cost, in particular with a progress bar)
3. Activate graph mode
4. See error (prompt to kill/wait), many times over.
5. Eventually see graph, but can't be scrolled or interacted. Chromium process is pegged at >1CPU of use constantly.

**Expected behavior**
logseq manages gardens with 3.5k nodes faster than this, shows progress bars where needed and doesn't prompt Chromium kill-tab dialogs (am I the only logseq user that has this many nodes? it seems unlikely)

**Screenshots**

**Desktop (please complete the following information):**
- OS: Linux paramita 5.8.0-53-generic #60-Ubuntu SMP Thu May 6 07:46:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- Browser: Chromium, fresh profile, no extensions
- Version: Version 90.0.4430.212 (Official Build) (64-bit)

**Additional context**
I have a Ryzen 4750U with plenty of RAM; Obsidian handles the same garden without any delay (although I know of course you're solving a more complex problem here, running solely on the browser).

Thank you so much for your work on this amazing tool! Please let me know if you need anything else here, I'm happy to run more troubleshooting.

Reproduce with the flancian/garden repository in Chromium, waiting through cloning and parsing before opening graph mode. Investigate the graph view and large-garden loading path; done means a garden of about 3,500 Markdown nodes loads without kill-tab prompts, remains interactive, and shows progress while setup work is running.

Written by the indexing model from the issue text.