Page MenuHome

Entering and exiting mesh edit mode uses a LOT of undo memory.
Closed, ResolvedPublicTO DO


Using SVN revision 45277, compiled on xubuntu 12.04 beta, 64-bit

Entering and exiting edit mode on meshes appears to leak ram. This is not obvious on low-resolution or medium-resolution meshes, or during modeling without mode-switching, but it becomes a serious problem when working with very large meshes and doing frequent mode switching.

To reproduce, start Blender and subdivide the default cube a lot. Then repeatedly enter/exit edit mode, and watch the RAM usage grow.

Alternatively (the way I discovered it), you can open the dragon rig file from the Sintel production files, and enter/exit edit mode repeatedly on the dragon model. RAM usage sky-rockets.

Event Timeline

Looked into this,
This isnt a bug, but agree its _really-bad_, mesh editmode stored an undo state when entering, so as long as you toggle editmode it keeps storing copys of the mesh.

Editmesh should really be improved to use some binary diffing.

leaving open... :|

Well, it's bad but it's just how current undo stack works -- it keeps fixed amount of undo steps in stack, not checks for memory usage or so. In fact, it's not only toggling edit mode which leads to enourmous memory usage, it's also any global undo stack which will eat your memory fast.
Wouldn't actually consider this is a bug, just good motivation to redesign undo system. Added extra item there

Ah, okay.

When I was working on the Sintel Dragon in 2.62, though, this didn't seem to be nearly as much of an issue. Recent SVN nearly freezes my computer after a few edit toggles, but 2.62 just breezes along fine.

Is this simply a difference in how much space the mesh representations take up? The reason I submitted it as a bug in the first place is because it seemed like a regression from 2.62 (e.g. I was forced to go back to 2.62 to get work done because of this).

Hmm, also, doing some further testing, it seems like the memory limit on undo is miscalibrated. When I set it to 512MB, Blender's ram usage still increases by over 1GB due to the edit mode toggling.

Hm, if it takes much more space in memory than in 2.62 release, probably it's something due to bmesh structures.Probably it stores mloops and tessfaces as well which isn't actually neededand which might cause 2x extra memory usage.
Would be interesting to investigate. Will assign to Campbell for now to check if memory usage might be optimized without requiring all that "packed" mesh storages.

Sergey, I dont think its todo with the BMesh structure (would only account for 5-10%),
I think its because BMesh undo steps store ALL shape keys.

... this is why some diffing is needed IMHO.

Aah, indeed now shapekeys are in CD layers and this is indeed might be improved in quite simple ways i think. The only question would be is if we're going to make such changes before release?

I know that this might be quite off-topic, but could we have something similar for shapekeys as well? I mean that shapekeys only store and apply changes that have been made. Currently every shapekey is a full copy of the mesh. With larger meshes and a good dozen of shapekeys (alone for facial animation) it is really memory and computing intensive. The last time i tried to use corrective shapekeys on a mesh with roughly 5.000 polygons i had to give up this idea, because i had 40 shapekeys already and it was so slow that i could not really edit anymore.

imo Undo should ideally only store Stuff if changed and if possible only the part that changed (this might be a slow operation as well?). Just an Idea.

Possibly reassign to Nicholas Bishop?

Global Undo does a binary diff on data chunks. If editmode in-out would leave the data unchanged, no undo memory would be needed. I guess BMesh stores a lot of pointers though, and these get re-generated on each TAB-TAB?

If shapekeys now store so much data by default; it would be worth checking on a way to re-use old shapes on exiting editmode...

bmesh undo is infact storing `Mesh` meshes (DNA data), just with no binary diffing.

Closing, marked as todo. More efficient undo usage is a great project to work on :)

Ton Roosendaal (ton) changed the task status from Unknown Status to Unknown Status.Feb 16 2013, 5:36 PM