Performance issues when working with larger .md files (With video footage)

Bug graveyard
, , ,
#1

Steps to reproduce

I’ve noticed that this error occurs mainly when you’re working with a larger .md file with many references to images and indentations.

Expected result

For the app to work equally as functional with large and compact file sizes alike. For the linked scroll (when working with ) to sync and function properly.

Actual result

The fist things that happen are that after a while of having the obsidian app running, things eventually become pretty slow (not in video).
Another observed side effect of working on .md files (with what I seem to think is many image references) is that the the scrolling becomes wonky. Every time I type text, the screen glitches out and I lose the place where I was initially typing.
If this explanation isn’t making any sense, please check the link to the footage in the additional information section.

Environment

  • Operating system: Windows 10 Home
  • Obsidian version: 0.7.3

Using CSS

Additional information

this is the link to the video footage described above.

High typing latency when authoring a math-heavy note with linked preview
#2

Thanks for the report!

If you do ctrl-shift-i, do you see some error in the console?

What computer do you have (specs)?

Does this happen if you keep the preview closed?

#3

This is the only error I get in the console (can’t access details by clicking/right-clicking):
image

Specs: MSI GS65 Thin
GPU: NVIDIA GeFORCE GTX 1070

image
image488×710 14.8 KB

Apparently, the glitching and bugging only occurs with linked panes. The slowing down occurs on any occasion where the .md file is full of data.

#4

Thanks.
@NikoasP98 do you have a sync service active in the background (dropbox?) ?

@Licat this may be connected to latex users expiriencinng slowdowns on big files while previewing.
Do we update the preview too aggressively?

#5

Yes, I use Google Drive and if it’s of any use, I use latex in my notes.

#6

CAn you send us the file where this behaviour is happening the most? You can put it on gdrive (or dropbox) and send us the link.

If you turn off gdrive. does this performance issue still happen?

1 Like
#7

The issue happens with or without gdrive syncing activated. Disabled syncing to test it out.
I’ll link the .md file and my image attachments folder.

LMK when you get your hands on the files so that I can delete them from my gdrive account as they clutter things up

#8

I can’t access the files. Can you put the fhe md file and the image folder in a zip file and share that?

1 Like
#9

on it! :slight_smile:

#10

Attached file for repro: https://www.dropbox.com/s/ptcx5288r6zuxb4/OBS_files.zip?dl=1

#11

This seems to be caused by the heavy use of lists (the whole file is a single list).

Summary: using markdown list, the app is unable to “break apart” the different parts of the document to be reused, which causes a full re-render of the list block (which is in your case the whole document).

Normally, when you use proper headings and markdown blocks (generally anything separated by a completely empty line in between), the app can recognize each block, and only re-render unchanged blocks.

It fails to do so with large blocks, such as if you write a really long paragraph, or in this case, the use of a continued list. This means embeds such as images, latex, code blocks, will need to be re-rendered every time, which is causing the performance issue here.

For now, I would suggest using proper markdown headings so parts of the document can be recognized as unchanged.

In the future, I will add some extra optimizations to attempt to reuse more things like embeds. This should hopefully solve most of the issue for this use case.

3 Likes
#12

Nice to hear the feedback. The reason I use the mentioned list format is because I want my files to be future proof for when Header Folding becomes available in preview mode. I like to view only certain blocks at a time and keep everything under a list to do so.

#13

Heading folding will work for plain headings I think, no need to put them all into lists.

1 Like
#14

I am going to archive this as we have made significant progress in this front in 0.8.2 and 0.8.4 If you still have issues, open a specific bug report.