> The time does not seem to scale with the size of the graph; it seems we have a complexity of O(1) here.
To be exact, the loading time is more near O(n) with n being the graph size.
Because when RoamResearch loads it downloads the *whole* graph as a flat json file from https://firebasestorage.googleapis.com/v0/b/... you can confirm that when opening the network tab of the browser developer console.
The time needed for loading the graph is relatively small compared to the (almost constan) time starting the app and loading all scripts. Therefore the size of the graph does not really matter - that may change if it were a lot larger but it seems that Roam can't handle larger graphs very well right now.
I beg to differ, graph size is often > 1-2Mb thus being larger than scripts that are loaded dynamically *after* the loading screen, if you look closely in the network console :)
I'am not talking about the time to load the scripts, but to run them. Try it yourself - download the app and measure the time from starting it until you can select a graph. This time is constant and way larger than the time to finally load the data.
Oh I see that we were not talking about the same thing, indeed after a specific X Mb of json file loading time, the json parse and db load has the biggest load time but until then it's not the db deserialize time but the serialized db that takes the biggest time. Never looked at what "X" we are talking about, I think it must be at least bigger than 5Mb to impact more the deserialize time than the download time :)
Oh! So much great work and effort done here. Wondering how the comparison with other apps will look like. Thanks!
We will see it in the next weeks starting with Logseq in the coming days.
Hello 👋, thanks for that great article! Founder of https://roam-bot.com here :)
> The time does not seem to scale with the size of the graph; it seems we have a complexity of O(1) here.
To be exact, the loading time is more near O(n) with n being the graph size.
Because when RoamResearch loads it downloads the *whole* graph as a flat json file from https://firebasestorage.googleapis.com/v0/b/... you can confirm that when opening the network tab of the browser developer console.
The time needed for loading the graph is relatively small compared to the (almost constan) time starting the app and loading all scripts. Therefore the size of the graph does not really matter - that may change if it were a lot larger but it seems that Roam can't handle larger graphs very well right now.
I beg to differ, graph size is often > 1-2Mb thus being larger than scripts that are loaded dynamically *after* the loading screen, if you look closely in the network console :)
I'am not talking about the time to load the scripts, but to run them. Try it yourself - download the app and measure the time from starting it until you can select a graph. This time is constant and way larger than the time to finally load the data.
Oh I see that we were not talking about the same thing, indeed after a specific X Mb of json file loading time, the json parse and db load has the biggest load time but until then it's not the db deserialize time but the serialized db that takes the biggest time. Never looked at what "X" we are talking about, I think it must be at least bigger than 5Mb to impact more the deserialize time than the download time :)