Reducing the memory footprint of obsidian

What I’m trying to do

I have a large obsidian vault. 20k notes, 50k images. I also use quite a few plugsin (dataview, datacore, omnicore, etc). The memory utilization gets quite high (often 6GB, I’ve seen it as high as 10GB). My suspicion is that the index is quite large. Since I don’t have paths in the image embeds, obsidian has to look to see where images are to display the embeds in the notes. I assume that is in the index.

Things I have tried

I have thought of two possible solutions. I prefer solution 1, but will do solution 2 if that’s the only way.

  1. I can go in and add the full path from the vault root to the embed codes for each image (I know how to do this). Obsidian should would no longer need to search for the image. But I still need to keep them out of the index. I can go into “Files and Links”>“Excluded Files” and add the full path to the attachment directory, but I’m not convinced that removes them from the index. I did add the folder to be excluded and obsidian could still find the images for notes even though there wasn’t a path to them. I like this solution best because it leaves the images in the vault, but (hopefully) doesn’t clog up the index.

  2. I would move the attachment file totally outside the vault but in the some folder as the folder vault. I could construct relative offset from the note to the images it uses (bunch of “../”'s and then a path). I would think this works, but it feels like a brittle solution. It may have the advantage that it gets them out of dataview’s/datacore’s index as well (and everyone else that has to have their own index).

I don’t need recommendations on how to write code to make the change. I’m just interested if anyone call tell me if either solution is likely to reduce the overall memory footprint of obsidian.

Alternative ideas of reducing memory utilization would also be appreciated.

I expect that excluded files are still indexed.

I’m under the impression that Obsidian is restricted to 4 GB of RAM as mentioned in Obsidian build without V8 pointer compression, altho I see now that the limit is per process, so maybe that explains the numbers you’re seeing.

1 Like

Well, I’m pretty sure the 4GB limit isn’t correct. Here’s my task manager.


This was from a few minutes ago.

I did remove the datacore. I did intend to use it, but I’m not convinced it’s ready for prime-time yet (I’ve seen a lot of datacore errors where it can’t index file – maybe it’s leaking memory). I also removed omnisearch since I rarely use it. I suspect both have their own indices.

The task manager snapshot is after i did this. I have 128GB of memory in my laptop. So, 8 GB isn’t a huge problem. 8.5 GB does seem like a lot.

Things have been working better, but since the problem is intermittant I won’t know for a while.

I think you are probably right on the indexing. I’m still planning on changing the links and splitting the vault. I guess ugly links are in my future.

It will be an interesting experiment to see how moving the attachments outside the vault affects memory.

Thanks for the reply

1 Like

@TheTao what exactly are you suggesting is incorrect - the V8 memory cage or the V8 documentation?

That looks like the OS level (Windows?) task manager reporting 8GB for the whole process.
That means it reports total process memory. The 4GB limit is the heap that’s accessible to user memory (aka JS object cage or V8 memory cage - Electron and the V8 Memory Cage | Electron) - i.e. what Obsidian can allocate.
Naturally, in order for user memory to be 4GB, the VM needs to allocate in addition to that to operate, so that’s why you’re seeing a difference.