When working with the links to Dynalist nodes without the explicit markdown format (i.e. just using the plain https link), Dynalist used to resolve the title of that node immediately. Now it seems that this resolution process takes much longer and I have to wait a long time (>10 seconds) until all links on a single page have been resolved.
Are you having performance issues on server side?
No, rather itâs intentional for the sake of server performance. The document youâre seeing is loaded with priority, and other document are loaded in the background, thus the 10+ seconds delay.
Before this optimization, when people have tens of tabs and restart their browser, loading all those documents at the same time nearly stalled the entire server a few times.
Is this causing serious issues for you?
@Shida can comment more on this if you need more technical details. Essentially delayed load for better initial performance.
Yep, itâs seriously an issue as I use this feature to create âknowledge mapsâ which are consolidating different nodes from different files into one view.
Having this slow performance will force me to manually manage the titles of the links which are likely to become outdated/out of sync with the original node name. Also this is a big negative point for efficiency on my side.
Would therefore really appreciate if this use case is getting addressed from an architecture/design perspective (please, please).
Weâve started deferring document loading recently for both client and server side performance reasons, but I recognize that you have a reasonable use-case here.
The issue weâve been trying to address are with users with a lot of documents (50-100), and users who has many Dynalist tabs open. Weâve been trying to let sessions to load documents gradually when these users refresh, or restart the browser so as to lessen the load on the servers.
Weâre working on better throttling and caching, which should eliminate the need for such measures in the future, so I believe this deferred loading should only be temporary.
In the meantime, we could draft up something like a (temporary) preference option for cases like yours, but weâll need a bit of internal discussion about how to implement this. @Erica?
1 Like
Yeah. Or if we can remove the temporary fix soon enough, we might not need such an optionâŠ
@Jan_Hutter, any follow-up thoughts on this?
And also, just an idea, maybe the desktop will work better for this use case, since all data are cached locally.
@Erica Thanks for asking. I havenât tracked the details but I did not encounter major issues lately with that feature - it started to work again as I was used to. Obviously the fixes/changes do work for my use case.
@Erica The issue started to happen again :-(. Any update on this from your side? Itâs really a big issue for me.
Hi Jan, âsorry for the late reply due to the holidays!
If the issue is acting up again, have you considered my previous suggestion to use the desktop app? Since everything is cached you shouldnât run into this issue any more.
Well, while I have the desktop app installed, I frankly donât use it. For me it is not usable as such because compared to the Browser version:
- It does not allow to change the zoom level (e.g. to make everything smaller)
- It does not support tabs or multiple views
I have typically 2-3 dynalist views open (as Tabs in Google Chrome). This works well in my multi-screen setup: I have two big screens where I can have one dynalist view on each screen. Itâs particular important for me as I use the linking feature quite heavily where I have the overview on one screen and the details on the other. Also, I am often working at different topics and want to have the notes ready without having to search for them or use the bookmarks.
You can do Ctrl+= to make it bigger and Ctrl± to make everything smaller.
This is the more deal-breaking issue, I see. Thatâs understandable.
Alternatively we can see how we can bring similar offline experiences to the browser.
Thanks for the scrolling hint. As the scrolling with the mouse wheel (Ctrl + mouse wheel) did not work I thought it is generally not supported.
Offline experience for the browser would be awesome!
1 Like