Entering and exiting mesh edit mode uses a LOT of undo memory. #30730

New Issue

Nathan Vegdahl · 2012-03-30T07:33:17+02:00

Nathan Vegdahl commented

2012-03-30 07:33:17 +02:00

%%%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.%%%

%%%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.%%%

Nathan Vegdahl commented

2012-03-30 07:33:17 +02:00

Changed status to: 'Open'

Campbell Barton commented

2012-03-30 09:14:08 +02:00

%%%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... :|%%%

%%%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... :|%%%

Sergey Sharybin commented

2012-04-05 19:07:55 +02:00

%%%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 http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Undo_stack%%%

%%%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 http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Undo_stack%%%

Nathan Vegdahl commented

2012-04-06 01:19:19 +02:00

%%%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).%%%

%%%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).%%%

Nathan Vegdahl commented

2012-04-06 01:23:20 +02:00

%%%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.%%%

Sergey Sharybin commented

2012-04-07 16:39:05 +02:00

%%%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.%%%

%%%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.%%%

Campbell Barton commented

2012-04-16 04:39:45 +02:00

%%%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.
%%%

%%%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. %%%

Sergey Sharybin commented

2012-04-16 11:06:19 +02:00

%%%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?%%%

Tobias Oelgarte commented

2012-04-16 13:35:30 +02:00

%%%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.%%%

Sebastian Röthlisberger commented

2012-04-28 20:00:08 +02:00

%%%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. %%%

Nicholas Rishel commented

2012-06-26 07:37:03 +02:00

%%%Possibly reassign to Nicholas Bishop? http://wiki.blender.org/index.php/User:Nicholasbishop/BMeshUndo%%%

Ton Roosendaal commented

2012-10-23 12:02:24 +02:00

%%%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...%%%

%%%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...%%%

Campbell Barton commented

2012-11-04 16:15:57 +01:00

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

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

Ton Roosendaal commented

2013-02-16 17:36:35 +01:00

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