Link resolution shows poor performance

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