Better if bigger, fewer documents or smaller, more numerous documents

Having moved over from the Workflowy world of one gigantic document to the Dynalist world opening up the capabilities of many documents… from a performance standpoint, is it better to:

Have fewer, big documents,

or

Have more numerous, smaller documents?

I could go either way, but I’m curious (and I’m sure I’m not the only one with this question) what document strategy going forward will maximize the performance of Dynalist for me, whether using Dynalist in Chrome browser, Windows desktop and Android?

Thanks… this will help me use this great tool to its fullest extent!

Mark

P.S. Thanks to the Dynalist team for doing much to improve the performance of this product!

1 Like

There may be technical advice specific to machine efficiency.

But for me the major issue is search. To search within the document is like Workflowy. You can edit the entries, such as change tags, from the search results. But this is not possible with a global search. It’s a more laborious process of zooming into the result in its context.

However, the document helps with focus, so I divide my workspace into the projects where I am likely to work for a couple of hours at a time. But I resist creating further documents, so I can have greater control over the searching.

When items are collapsed their children are not injected in the webpage structure, so you can have thousands of hidden items and only the visible will have any impact while document is loaded. I have few huge documents with more than 1000 items (including Propædia, an outline of all possible human knowledge ), and dozens of smaller ones. It doesn’t matter for loading time or in any other moment which one I’m working on, and also on which platform. Even Android app is just a wrapper for web app. Use it in whatever way you like :slight_smile:

1 Like

Thanks good insights. Interestingly, I wasn’t thinking about the client side, but the server side. Good hearing about client side. How about from the Dynalist team: which is better server side?

Thanks

My guess is that it doesn’t matter that much, but if your documents are smaller on average, the document you’re on loads and shows up a bit faster, while other documents load in the background.

@Shida?

I would say that from the server’s perspective, having smaller documents, and more of them, should get a better performance. This is due to the fact that for any change happening to the document, our server loads the entire document into memory. A larger document means more work in terms of loading the document from the database and saving the document back, as well as just using more memory itself.