Obsidian UI freezes on rename (or move) in large vaults

Bug graveyard
, , , ,
21

And just renaming things programmatically is not that simple because links could have absolute paths such as

[[___Attachments/Note1/Image2.jpg]]

or just

[[Image2.jpg]]

And simple text replacement won’t address such cases

22

I tried to identify what exactly is making this poor performance via taking some files and folders out from vault. But I couldn’t identify the individual file that causes the problem.

I could only narrow down the problem to a few folders.

Attached the problematic vault for devs to investigate

https://drive.google.com/open?id=1RR0FvR_4AKDPNoXrjnp_td3m4bQHlH_D&authuser=mnaoumov%40gmail.com&usp=drive_fs

23

I am having very similar issues for a week or so.

UI just freezes, it happens so much that I can’t use Obsidian any more

1 Like
24

how big is your vault?

25

I found the issue on my side. its the plugin Checklist which has issues with the latest obsidian update.

26

Before opening a new bug report, please search the forum for duplicates and follow the Troubleshooting Guide.

Steps to reproduce

  1. Have a large vault (50k notes) with many links between them
  2. Rename some note that has some backlinks

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

No lags

Actual result

Huge UI lag during the link update (5+ s)

Environment

SYSTEM INFO:
Obsidian version: v1.4.16
Installer version: v1.4.13
Operating system: Windows 10 Pro 10.0.22621
Login status: logged in
Catalyst license: insider
Insider build toggle: on
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional information

During my performance investigation, I found the bottleneck in the app.metadataCache._getLinkpathDest function called many times from runAsyncLinkUpdate

I made the following fix that heavily improves the performance

const _getLinkpathDestOriginal = app.metadataCache._getLinkpathDest;
const resultCache = new Map();
app.metadataCache._getLinkpathDest = function(origin, path) {
  const key = `${origin}|${path}`;
  let result;
  if (resultCache.has(key)) {
    result = resultCache.get(key);

    result = result.filter(f => !f.deleted);

    if (result.length > 0) {
      return result;
    }
  }

  result = _getLinkpathDestOriginal.call(this, origin, path);
  resultCache.set(key, result);
  return result;
};

As I am using only markdown links with relative path, I think my implementation is quite safe to use. Not sure if it is reliable for Wikilinks usecases.

1 Like
27

I prepared a test vault with just 10k notes but they all reference each other.

The vault becomes unusable

This test vault can be used by the Obsidian team for testing all the performance bottlenecks

Vault.7z.zip (51.1 KB)

2 Likes
28

Well it seems your “unmanaged” attachments are causing this issue, just compress or delete your pictures.
Same for pdfs.

Would be comfortable to dump anything in the attachments folder, this is understandable. Some cleanup is necessary from time to time.

29

Nope, the attachment theory is fully disproved. Please see my message above with the test vault, it has zero attachments

1 Like
30

Hey there!

Faced same problem here: Slow note creation/rename

mnaoumov’s solution worked well to make creation/renaming 10x faster.

Please, notice this bug, and bump this topic if your team needs any help fixing it.

1 Like
31

We do not think that the code outlined by mnaoumov covers all cases. Users run it at your own risk.

We intent to address this at some point, we have had higher priority projects.

32

Is your cache implementation trustworthy with regards to files moving after they’ve been made a member of the cache? Would it not then return the original path to the file before the move?

A similar case could be argued if a file is renamed, but in most cases that would lead to a cache miss, and a trigger of the original method.

So I’m thinking this cache implementation would benefit from some sort of cache invalidation, potentially from a hook on the events related to moving and/or renaming files.

33

In 1.7.2 some work will be done to improve the speed of rename operation.

If you have a vault with less than 1 M links and still experience a severe slowdown, please, open a new bug report.

If you have more than 1M links, continue here:

34

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.