Proposal for Multi-Core Processing to Boost Obsidian's Efficiency

[Sam12]

@Sam12

Recently, I’ve devised a method to indirectly enable Obsidian to utilize multiple cores. Although this approach won’t work for canvases and lists, it allows different windows to use separate CPUs. The method involves using mklink.

1. Create Multiple Vaults: Copy multiple .obsidian folders and create new folders to establish new Obsidian vaults. By linking notes across vaults, they can share the same folder.
2. Assign CPUs via Task Manager: Use the Task Manager to assign different CPUs to each vault, enabling different windows to operate on separate CPUs.

For more details, you can refer to this forum post.

Thank you both for your replies. I tried using Obsidian URI, but it seems it cannot achieve the functionality similar to !. Additionally, I found that neither method can effectively handle situations where there are attachments in the file. The only issue I have discovered so far is that if it is a canvas file, the images in the canvas file cannot be displayed correctly because it does not use the shortest path. I think this method can effectively solve cross-vault referencing. Advantages: …

In this post, I enabled two sub-vaults to be accessed by the main vault. Note that this doesn’t mean creating a new .obsidian folder under the main vault. Instead, it involves using mklink /j to link the folders that need to be shared.
However, this method could have a couple of drawbacks. First, updating configurations requires synchronization, which can be very time-consuming. Second, if multiple windows edit the same file, it may lead to sudden content loss.

I tested it today and announced the results. This method can effectively solve the problem mentioned in this post! One window is used for previewing, and another window is used for editing. The preview window will not have any performance impact on the editing window.

Reading mode (and Canvas): Implement some form of progressive rendering for long lists

@WhiteNoise

@WhiteNoise

The problem is not the canvas, if you open that document in reading view, outside the canvas, you get the same effect.

I think this is also a very good solution! Each new window reopens the vault (similar to using copy .obsidian + mklink /j here), instead of independent windows from the vault. This way, for multiple windows, multi-core usage can be achieved!! This doesn’t require a large project, and I think the development team can consider it! The drawbacks of this method are:
firstly, it may cause different windows to edit the same file, leading to content loss, especially with plugins like Easy Typing or Update time on edit;
PS：I’m not entirely sure if it’s solely due to them. I believe it happens when two different windows open different files, and during refresh (read), modify, and save, they don’t sync. If we remove the auto-update plugins, then this synchronization issue can be resolved.

secondly, this method does not work for Canvas and list.

Currently, I manually copy .obsidian (mainly to ensure that the vault’s plugins, themes, and CSS snippets are the same) + mklink /j for the required directories. It’s important to note that Canvas cannot intelligently recognize file paths, so we must ensure the consistency of relative paths to achieve similar functionality, which is equivalent to reopening the vault (different main windows). Another issue is finding the corresponding PID. It is confirmed that AHK Window Spy cannot find the correct PID. The only way is to open a large Canvas and find the corresponding PID through high CPU usage, then allocate different cores through the task manager. However, it seems that not allocating cores might also achieve the same functionality.