For each of its undo states, Blender stores a separate copy of the file. A new file is loaded every time you press undo. Undo happens at the same snail’s pace as loading a the file from the disk.
Wow, I didn’t expect it to work that way. It sounds very inefficient.
Are they really saved on disk and not in RAM? Do you know in which path these copies are stored?
1 Like
I fully agree that undo performance is really underwhelming at the moment, but I can at least understand why it wasn’t addressed for the release of 2.8 with all the time it took to get all the other changes done to finally get the project out the door. 2.8 getting released was way overdue.
However, 2.81 needs to address this. I would rather wait an extra month or two of not releasing 2.81 if it means a more optimised undo system, since it is that important.
This .blend file in this report:
https://developer.blender.org/T67257#727630
Undo is slow (about 7 sec in my machine) and CPU goes to 100% (the one who reported talks about 1 minute). Scene takes 4GB of RAM (6GB total in System, 8GB remaining free on my machine). Perhaps in some cases it depends on the CPU that each one has?
Edit:
When the scene is loaded for the first time, there is also a heavy work of the CPU. So slow Undo related to disk copies may be possible. I just can’t believe that it works that way 
Edit 2:
I have done separate tests with .blend file and blender from SSD, and .blend file and blender from HDD. There seems to be no differences in time, both have similar Undo times.
1 Like
we talk about that here
It has been confirmed by developers that the entire scene is reloaded with each undo step, but I did some tests myself. I think Blender tries to keep all of the undo steps in ram but at some point the memory overflows into virtual memory. So there’s no physical location other than your page file. It’s amazing a 500 mb file takes up 32 gb of ram while working, solely based on the undo steps.
So unless you overflow your physical ram you aren’t using the harddrive, but you are still fully loading the entire scene from ram rather than the one object that has changed, much less a delta of the one object. It’s completely inefficient and needs to be fixed.
you didn’t want to believe me … 
It is not a matter of believing or not believing.
I would really like to know how Undo system works. @DanPool thinks those copies are in RAM in principle. But you @nokipaike said that SSD influences. And my guess was that SSD does not influence unless RAM is filled.
About the .blend file shared in that report in my message above, I have not been able to verify that SSD is faster than HDD.
Perhaps there are multiple causes about why Undo is slow.
Yes, that is what seems to be happening with that .blend file of that report. Each Undo step seems to take the same time that it takes the scene for be loaded the first time. CPU usage is similar too.
1 Like
i think with the multi object editing blender now stores undo steps for each object so they have to be added and removed from the undo history…etc, maybe this part is also causing slow downs if you have a large scene to work with.
Btw. for undoing several steps at once I strongly recommend using the undo history instead of pressing CTRL-Z multiple times. This is by no means a solution but it can be very helpful.
1 Like
instead it is really in this way … in fact people start having problems as soon as they start to have many objects in the scene scene … and it is a Chinese box, because the more objects increase, the more the IO between ram and disk increases, more undo is slow.
Having said that, it is not possible that to have a decent undo you must have 20 GB of ram … or a workstation of the NASA … hehehe
Anyway here are the differences between a hd on sata, an ssd and a m2 …
(in reality the hdd hardly exceed 80 MB / s)
Hi.
Yes, I know about SSD. You also inquire about cell types and lifespan. Intensively using swap/page file in SSD is a bad idea. So if your system has low RAM, you better just add more RAM.
In any case as I said before, here the root of the problem would be the excessive and inefficient use of RAM if that were the problem.
let’s make things clear …
I have 16 GB of RAM, I think that’s enough for me …
and the problems with the undo are the same
my gpu has 2 GB of video ram, I don’t know if this influences …
but in everything it is a bad thing …
I also have 16GB. Then you will be able to verify that in the case of the .blend file of that report in message above, RAM is not filled completely (no intensive use of virtual memory) and Undo is still slow. Reporter talks about a minute, I get 8 seconds. So as stated before the problem is more related to how the scene is reloaded from RAM in every Undo, therefore slow Undo times will depend a lot on the CPU that each one has (at least with that .blend file)
1 Like
probably you’re right, but I’m pretty sure that those who reported the difference between an hdd and a ssd (probably even with the operating system first on hdd and then on sdd) are right as well, they would have had no reason to say bullshit for a placebo effect
So at work I use maya and blender on the side, I am often working with CAD data of cars, the machine I work on has 64gb of ram, twin octocore xeons and a 1tb SSD, Undos in maya can be instant if its a simple hide and unhide, but blender will hang for up to 30 seconds with the sort of data we work with. It’s really my biggest gripe with the program and the one that stops me suggesting it to the rest of the team, been a blender user for 13 years now, would happily ditch maya if I could 
2 Likes
I work with 32 GB ram and undo is still as slow as everybody else’s. It’s really, really hard to max out my ram with Blender, so you guys with 16 GB shouldn’t be too worried either (although 16GB is starting to become more like the bare minimum to run more than just a few softwares simultaneously).
As for the SSD part, it’s pretty well known that programs and files on SSDs read faster than on HDD drives, which are more concerned with storage size than speed by nature. However, that still doesn’t mean that you will magically get faster undos in Blender that will solve all your problems. It is primarily a software issue, not a hardware one, and it can only be solved with new code.
Since I started learning Blender last December, I was kind of surprised that people didn’t take notice of how inefficient the undo system was when handling history states in all the years Blender has been around. Thought that would have been a pretty big priority issue to fix in the past as well. Still, it seems to me that 2.8 has made the development a lot more focused than in previous eras of Blender development, so I can’t really be that harsh, especially when it is open source.
1 Like
Funny but sad to see a bug closed with “known limitation”… feels like when I report UI bugs which get closed as “design issue”. Sure, they can close the bugs, but the problems remain.
2.8 is a great leap forward, but I still get the impression that Blender developers love to dig into technical things, rather than usability things… which I guess is logical… they’re coders, not artists… well, except for the new sculpt guy who seems amazing.
But this ties in with the edit mode performance of 2.8 reported here.
Before 2.8, people didn’t want to use Blender. Now, people want to, but can’t.
3 Likes
There is a difference between a bug and a design limitation. I have reported issues as well that were considered as by design and even got the topic closed, but that doesn’t mean that it will not get looked at (once got help with a built-in add-on on the bug report forum despite it being argued as by design).
A bug report forum is supposed to help compile the faults of a program that are not by intended design so they can be addressed. It is not meant to be a feature request forum. We have RightClickSelect, this forum, Blender Artists, and possibly more places where that type of feedback is welcomed.
As for the issue regarding slow undos, the Blender Foundation has said multiple times that they are going to work on it. Hopefully that solution will ship sooner rather than later.
Yes, I know it’s a bit frustrating. But on second thought, many things have been completely redesigned and written from scratch in Blender 2.8. We should be amazed about how things are working in such a short time of development. We even have very good compatibility with old scenes of 2.7x, which I think is fantastic, I really thought it was not going to be so good. Surely we will be having improvements in performance in new releases.
“Known limitation” just means that developers are already aware of the problem.
So let’s be patient, continue testing and see if we can provide useful information to developers.
1 Like