Beyond a certain page count, Graph View no longer generates a layout and becomes useless

[Lunariz]

Describe the bug

When hitting some limit (I hit it at around 600 pages), the Graph View will refuse to perform the layout algorithm, and displays pages in an unstructured grid instead. It technically still functions, but all its value is lost.

To Reproduce

Steps to reproduce the behavior:

1. Have 600+ pages (or whatever the hard cap is)
2. Go to Graph View

System Information:

• Device: Desktop computer
• OS: Windows
• Browser: Chrome

Additional context

I understand that this is intentional to prevent large databases from straining the servers, as the layout algorithm is probably O(N^2). However it made me quite sad to see the feature disabled as a result of my enthusiastic note-taking

[MatthieuBizien]

I am experimenting with UMAP and the results are quite interesting. It would need some fine-tuning, but the result out-of-the-box is already better than Graph View. If I'm not mistaken, it is O(n.log(n)).

The graph of my notes:

[GamingCoder]

I can confirm that I am having the same issue with around 650 highly connected pages.

[Stvad]

stopped checking it a while ago 😅

[vijayshankarv]

I am in the same boat. I loved the code layout view 😢

I think I hit the limit at some point and now I don't use the graph view at all which makes me very sad. I think the growth of the graph view would be somewhat slow, so there might be an algorithm that does not need to recompute everything from scratch?

[agentydragon]

I think having a graph view of the whole database will eventually be useless for all but trivial databases, even if it somehow were to be laid out nicely. The full graph will just be too dense to read usefully. But showing, say, the k-jump neighborhood around a starting node, or only a given subset of nodes, might be ways to keep it useful.

[tntmarket]

The open source Roam project has an open discussion about this topic: https://github.com/athensresearch/athens/issues/21