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
I think we’re past the point of giving useful information to the developers. It’s more of a “we need to make sure this fixed soon” type of situation. We need to make so noise until this is addressed. I bet I lost an hour of work this week because of undo performance working with this cad data…funny thing is that I had to work an extra hour today to finish up before the weekend.
edit: By the way…it’s pretty awkward with a client looking over your shoulder while you work: “Lets try this…no that doesn’t work go back to what we had before”…(silence for more than a minute while we go through several undos)…“ok lets try this, but maybe save first so we don’t have to use undo.”
All of this after I spend 15 minutes talking about how great my open source software is when I pick him up from the airport.
3 Likes
I have isolated this couple of objects from .blend file from the report above, and saved from 2.79 to compare:
http://pasteall.org/blend/index.php?id=52153
Subsurf modifier in 2.8 with Quality=1 makes Undo almost as fast as 2.79. With Quality=10 after making some change in scene and then Undo, it takes about 10 seconds on my machine.
It is a well known problem that the new Subsurf modifier with OpenSubdiv needs optimizations.
This may be based on old information, but a coder friend of mine when I approached him about bringing open subdiv to 3ds Max said that it was only fast with predefined topology. As soon as you add the capability of editing the topology, the optimizations break down and require additional processing. I’m hoping the devs have done their research on this, though and can get open subdiv to perform like the old method of subdiv.
Again this is based on info that is old…from ten years ago or more.
All those with problematic scenes could do a quick test setting from Render tab, Simplify, Viewport Max Subdivisions=0. This to know how much subsurf modifier influences your scene, and to try to find other causes that slow down a lot Blender and undo system.
Just adding my voice to the discussion - I have noticed that Blender’s Undo performance is dismal. Simple undo’s - like moving a bone and hitting Undo - can take 15 seconds or more, and forget about doing several Undo’s in a row - you’re likely to crash Blender.
Also, a warning: For those who are storing data - like projects - on an SSD: You should be mirroring those drives/folders to a HDD on your system if possible, maybe backing up to online storage. I recently lost 2 years worth of work on an SSD that just decided to “blank” itself. One moment I was working, the next, my system blue-screened, and when I rebooted, the drive was gone. Disk Manager said that it needed to be “initialized” (I didn’t). I pulled the drive and sent it to a service specializing in recovering data from SSD’s - and they said it was blank. At least with a crashed HDD, you can usually recover data. A very hard lesson learned.
I still work on an SSD, but now use a program called Bvckup (yes, it’s spelled that way) to instantly mirror my data onto a second HDD that backs up onlilne at night.
2 Likes
I agree and have been about to make a topic about it because its frustrating. 2.79 didn’t have this issue I believe so I wonder why its happening on 2.8. Haven’t read the entire post so excuse me if anyone mentioned anything about that. Just here to support the feedback.
Another warning: do not use your main ssd for swap files. SSDs are very limited on how many writes they can take and the os is constantly reading and writing in a swap file. So you’ll kill a drive quickly by doing this.
1 Like
Swapping doesn’t happen that often to have any significant impact on SSD life, especially these days. One faulty SSD should not be a reason to spread tons of myths about SSDs in general. I’d say 5 years from now, almost no new PCs will have mechanical hard drives anymore. SSD will be both cheaper and faster, and no one will care about handling them in satin gloves.
To put that in the perspective, I’ve bought my first SSD in 2011 and used it as my OS drive (including pagefile) for 7 years. It still works well to this day. If you do heavy video editing or simulation using cache which overwrites let’s say 60GB of data 20 times a day, then yes, you should get specific SSD drive just for that cache, but when it comes to regular OS pagefile, you are completely fine.
Most SSDs are built in a way that if you overwrite their entire capacity every day, they should still last about 5 years.
Welcome to the internet where anyone will contradict any statement with a “well actually…” whether it has anything to do with the subject or not.
Well, actually… I just got finished stating that I have 32GB of ram. That means that my page file is at least 32GB, right? And my hard drive light was lit for 9 hours on Friday…You’re talking about 60 GB of data 20 times a day…I’m talking about 32GB every moment of a 9 hour work day. I’m pretty sure that’s more than 20 times…actually.
Edit: not that it has anything to do with this topic. Fry your hard drive if you want. I was looking to help out people who don’t want to do that. But more on topic: how about that poor undo performance, eh?
You started the SSD discussion in this thread I just wanted to make it straight. There’s lots of misinformation about SSDs out there, especially when it comes to reliability. And most of it is false.
1 Like
This is a known limitation of the current undo system.
I’ve checked the provided file from bug reports. I have i7 [email protected] CPU, fast NVME drive and 64GB RAM. Undoing simple movement takes 7 seconds. Using faster drives or CPUs is not a solution. The undo system has to be rewritten. I hope new fundings will help resolve current limitations.
2 Likes
in the current situation, 7 seconds is a nice goal … in less efficient systems they even reach 20-25 seconds …
Guys, have you think in make a basic scene, a test protocol,… to have a common guide of perfomance independent of the user personal scene?
Also you can see the difference in perfomance between different computer with different specs.
in the current situation, 7 seconds is a nice goal … in less efficient systems they even reach 20-25 seconds …
It’s not a nice goal. Waiting is not a solution. If Blender seriously wants to compete with major 3d apps this needs to be fixed.
2 Likes