For me it’s always but I started using Obsidian just a few weeks ago. I had the same issue on Windows 10 and now on Windows 11
Ahh okay, fast reply! 
What’s your folder set-up like? Are they all self-contained within one folder or have you got many different sub-folders scattered around?
I’m also wondering whether you’ve tried this testing in a brand new vault with around 10 notes to see if the scale of the vault is the issue or if it’s something else.
If you’re able to simplify the problem to something that’s reproduceable it would help a lot.
My notes’ folder structure.
https://drive.google.com/open?id=1JkQGrWkeUGLkFIDlnINC1FZq0s6KK__d&authuser=mnaoumov%40gmail.com&usp=drive_fs
As I migrated them from Evernote, the folder structure is far from ideal but I don’t know an automated way to make it better
On a new vault, rename is instant
Judging from that link you sent, my guess it has something to do with the non-ascii filenames. You’ve got a lot of files there with (russian?) names.
I also see a few dots in those file names, which have been known to cause issues in the past.
Since you’re a programmer, you could try duplicating the vault, use a Python script or something else to rename every file (and its links) to something using ABC123 ascii characters, and then test again to see if you get the same issue.
If it’s not that, it could be having trouble with the file encoding. I imagine it has to encode the file using a different format the moment different characters are used.
If the file encoding has to account for significantly more characters, maybe that would be enough to lag the application with ~10k notes.
I just checked that the lags appear only when I put my ___Attachments folder into the vault. All other folders with thousands of Russian named notes don’t seem to have a serious impact on the performance
Nice! Now to remove things at random and see at what point the lag clears up I guess.
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
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
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
how big is your vault?
I found the issue on my side. its the plugin Checklist which has issues with the latest obsidian update.
Before opening a new bug report, please search the forum for duplicates and follow the Troubleshooting Guide.
Steps to reproduce
- Have a large vault (50k notes) with many links between them
- 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
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)
1 Like
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.
Nope, the attachment theory is fully disproved. Please see my message above with the test vault, it has zero attachments
1 Like
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
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.
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.