Re-rendering live preview/reading mode tables by moving lines, table rows or columns (shortcut) is extremely RAM intensive and a memory leak that leads to nonresponsive app

Steps to reproduce

  • Start a new vault, such as the Sandbox vault (? icon next to vault switcher, Sandbox vault)
  • Make a table with a reasonable amount of rows and columns, something like 11x31 works very well but you can already get hangs and RAM spikes with 7x7 or 9x9 tables
  • Fill a few of the cells with a single character or so, it doesn’t have to be full but it’s nice to be able to visually distinguish when the rows and columns are moving. You also need to have something in the table. Example is the table in this file:

table.md (2.3 KB)

  • Presumably you made the table etc. in Live preview mode, or with Source mode + Reader mode next to eachother. Every instance of a Live preview or Reader mode representation of the table will linearly increase RAM spikes

Approach 1 (Live preview table movements)

  • Set the hotkeys “Table: Move row down”, “Table: Move row up”, “Table: Move column left” and “Table: Move column right” to convenient keys, such as Ctrl+Alt+ or Alt+Down/Up/Left/Right
  • Go wild spamming the hotkeys, or do it more methodically
    • Every move will spike RAM a bit
    • As the move is worked out or something over maybe 10 seconds, the RAM comes down but to a higher level than it was at originally
    • I move the column in table.md right-to-left and back one time to get 22 moves in, then repeat that five times for 110 moves:
Moves Peak RAM Settled RAM
0 - 250 MB
110 500 MB 300 MB
220 1.4 GB 700 MB
330 2 GB 1 GB
440 2.6 GB 1.2 GB
550 2.8 GB 1.5 GB
  • As you reach maybe 2 GB of RAM use, Obsidian stops writing the .md file changes to disk
  • As you reach maybe 4 GB of RAM use, the application fails to render anything and becomes unresponsive. This includes the Settings window etc.

Approach 2 (Source mode line movements with a Reader mode copy of the note open)

  • Set the hotkeys “Move line up” and “Move line down” to convenient keys, such as Ctrl+Up/Down
  • Spam these hotkeys up/down for a while. Within about 5-10 seconds you will see your RAM spike
    • If you have more reader mode copies of that note open, you will get linearly more RAM usage
  • The RAM usage also doesn’t come down

Did you follow the troubleshooting guide? [Y]

Yep, this happens:

  • In my actual vault with my actual table (huge) very quickly (although I don’t have my RAM open in normal operation to see the memory leak, and lose data as a result)
    • Also with all plugins disabled
    • WIth hardware acceleration on/off
  • On a new vault with tables of size 7x7 (after a long while it hangs a bit), 9x9 (relatively quickly it hangs), 11x31 (frequent hangs)
    • Also with all core plugins disabled
    • Also with installer version updated to latest version
  • In the Sandbox vault

Also:

  • The RAM usage increases on an Obsidian process, but not on the one called after the Vault
  • There’s no sync software active in the new vault or in the sandbox vault; I don’t use OneDrive and only Git, but it’s not set up in either vault.
  • The antivirus (Bitdefender) has no change in RAM whatsoever; disabling different components doesn’t change the RAM from spiking nor the RAM from settling at a higher level than before
  • PC restart changes nothing

Expected result

There shouldn’t be a memory leak in rendering tables

I expected big tables to be some performance issue, as it sounds intuitive they are performance-heavy, however it should never be a memory leak to move rows and columns a bit:

  • This happens on any size table as long as it’s being rendered in a live preview or reading view
  • It’s a memory leak, because the RAM is never cleared fully - the resting RAM keeps increasing
  • The application crashes a while after changes are stopped being saved to file, causing enormous loss

Actual result

As RAM reached high enough levels, it stops files from saving (maybe ~2 GB) and then the software stops responding (maybe ~4 GB) so you can easily lose work over 30 min to some hours.

Environment

SYSTEM INFO:
Obsidian version: 1.13.4
Installer version: 1.13.4
Operating system: Windows 11 Education 10.0.26200
Login status: logged in
Language: en
Catalyst license: insider
Insider build toggle: on
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none


Additional information

Sandbox vault performance recording

  • Ctrl+Shift+I > Performance tab > Record
  • ~45 seconds clip of spamming the move table row/columns around in the table.md file

  • Frames
    • 3.4 s dropped frame after ~30 seconds
    • Majority of frames is partially presented
  • Keyboard interactions
    • 12.2 s “long interaction” the longest, showing the most intense hang
    • Most interactions some 4 seconds

  • Errors?
    • “Layout Forced reflow is likely a performance bottleneck” repeatedly fires (all red blocks) during the 12.2 keyboard input delay
    • “Recalculate style Forced reflow is likely a performance bottleneck” repeatedly fires after some keyboard input delay, maybe 8 seconds in

  • Memory
    • Everything except GPU memory seems to go up over the entire duration; but the 17.7-136 MB of the application running the vault ISN’T the size of the RAM spike I’m talking about
      • It seems the JavaScript garbage collector just clears the JS heap, but something else holds the memory leak
    • Nodes goes up from 4,000 with an unmoved table to 600,000 after some seconds of spamming; Listeners goes up similarly
    • Documents goes up and dumps from 4 at the start to 130 at the peak

  • Insights about INP breakdown, Optimize DOM size and Forced reflow

Ctrl+Shift+I Memory recording

  • 874 MB snapshot over about 30 seconds of spamming moves
    • Several functions have contributed enormously to this retained RAM

  • Each call under “function” has almost exactly 1.2 MB contributed to retained RAM

  • Statistics overview shows absolute vast majority of RAM is ~689 MB of “non-JS objects (such as HTML and CSS)”

From what I can tell, those HTML/CSS objects aren’t cleared

Developer console

Over all the spamming in both tests:

Attempts at replication by Discord users

[10:10 PM] Roam: Can’t replicate on my end, I’m on linux though

[9:36 PM] purple penguin: no RAM change, system and background Firefox are using more than Obsidian I’d estimate 30 times in quick succession left and right. 30 up and down, maybe 20 mixed in all directions
[9:37 PM] Alistaire: I moved it 5 times all the way right and all the way left [110 moves], and RAM spikes 500 MB
[9:39 PM] purple penguin: in the fourth time going right, it slowed for what felt like less than a second then recovered, no spike

Thank you, I didn’t manage to get it to crash.

However, I did notice an anomalous RAM usage, especially during the first moves.

will be fixed 1.13.6. ETA unknown.