Undo Performance Must Be Addressed

I’m working on a large scene of imported cad data this week. Undo on the scene is taking 17 seconds. Please address this for 2.81. The scene data needs to be broken up into smaller chunks, or deltas need to be stored; either way, loading the entire scene anytime someone hits undo is not efficient.

I’m putting my foot down. This must be addressed soon.

5 Likes

There are several similar threads about this issue:

https://devtalk.blender.org/search?q=undo%20category%3A13

I don’t call two threads “several”. Either way, I want to bring this up again in a way that one of many posts on an existing thread would fail to do.

There’s reports from BA that undo performance is a lot snappier if Blender is on an SSD drive (as opposed to a platter).

I have Blender 2.8 on an M.2 Drive and I’m not waiting 17 seconds for an undo in most cases. That said there’s still performance issues, but Campbell has expressed interest in improving the situation for 2.81.

3 Likes

Please, where can I read that report everyone is talking about.
The only way I can think of this happening is that the user has little RAM in the system, and therefore virtual memory on disk is used, which would slow it down further. So maybe having an SSD can help those with low RAM in the system, but I don’t think that is the root of the problem in slow Undo.
If we continue with these rumors without being proven, this will generate even more confusion.

I have SSD disk, I have noticed that Undo can become slow in certain circumstances. Now that I begin to read all these rumors, I will be more attentive when it happens again to try to replicate the behavior.

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 :pensive:

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 … :slight_smile:

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