Blender should utilize much more system resources

Blender viewpoint should utilize as much system resources that are available.

When I have a scene with many millions of polygons, Blender starts to severely stutter.

Windows 10 task manager shows that my CPU usage isn’t even 10% and I’m also not using very much memory.

In order to prevent slowdowns and stuttering, Blender should be multi-threaded for as many CPU cores that are available, and also use

Be sure to let the devs know when you figure out how to offload your GPU bottleneck to your CPU. I’m sure there’s a prize waiting for you.

Some processes in Blender that are still single-threaded could be optimized for them to be multi-threaded processes. But this is not so easy for developers, and sometimes it will not even be possible to do so due to the nature of the process.

What is your GPU? If the slowness in your system occurs mainly in Material Preview or Rendered Mode (but not in Solid mode) it is very likely that the problem is due to the GPU and not due to the CPU.

I have a Core i7 8700K, 16GB DDR4 3200MHz RAM, and two-way SLI GTX 1080.

You have a powerful GPU and I don’t think that’s the problem (except that for some strange reason your system is using the intel iGPU instead of nvidia).
There is an AMD developer who is interested in collecting information about which tasks in Blender are still single threaded. If you want to collaborate, you could research about which single threaded components/processes/tasks are slowing down your scene and then mention it in this thread:

You keep in mind that there they are requesting that they be indicated very punctually and precisely which is the Blender component/processes/tasks that is single thread, so you should investigate your scene and detect the single thread feature of Blender by monitoring with a good CPU monitor that indicates activity of each thread separately .

PS: If the slowness of your scene is due to Subdivision Modifier or Multiresolution Modifier, you save the trouble of analyzing things. Everybody knows that it slows down everything for animation and it will stay slow until OpenSubdiv has hardware acceleration feature.

To begin you should be describing better what you doing
One thing is having many millions of polygons which tells nothing. What is even many? 5? 200? 1000?
Another thing in is telling specific amount of polygons in specific mode, under specific operation, modifiers and so on… along with your hardware

Further task manager isn’t that great for measuring hardware usage…

I think everyone agrees that Blender can do with some more optimizations that’ll make things faster, but I’m not sure if your argument is 100% the answer.

When processing data, you have a few knobs to tweak to make things faster.

  • Process things faster (for example, faster CPU, or use a language that is “down to the metal” like C, C++, or Rust)
  • Process more things at once (Multi-threading, SIMD, etc)
  • Caching/storing more things in memory (for example, baking animation to geometry deformation in memory to skip calculating the rig)
  • Process less things (reduce the size of the data structures)
  • Process things more efficiently (handle the data in ways that makes the best use of the computer’s hardware, only calculate when needed, use data structures and algorithms best suited for certain tasks, etc)

Blender’s optimization issues could be related to any one of those things. Except the first option. The majority of Blender’s code is in C/C++, so it is likely that the processing won’t be faster. However, things like making more use of the system’s memory or multi-threading may not make sense for a given task. For example, let’s talk about the depsgraph. Basically it controls what drives what, and what needs to be updated when (for example, moving an object along its x axis will update where the object is or manipulating the foot controller in an IK rig will drive a bunch of things that will probably drive a bunch of other things and so on). While the depsgraph is multi-threaded, there is a limit to the number of threads that will actively be calculating something based on what’s evaluating in the graph. For example, if you have a machine with 32 cores and you’re only updating one object, then likely you’re only ever going to use 1 core. However something like a path tracer will likely always benefit from more cores because each ray traced doesn’t have any dependencies. Also, some things may be extremely efficient, and could potentially become less efficient the more threads it uses. Lastly, there’s some data structures that may be really efficient for one thing, but not very efficient for another. For example, Blender’s mesh structure (from my understanding) looks great for editing meshes, but it may not be as efficient for doing something like iterating over every single vertex (due to the heavy use of pointers/list structures vs arrays). So, there may be need for another mesh data model for other tasks, and that also adds some performance and maintenance considerations.

So, while I think the argument of Blender could do with some optimizations is (and possibly will always be) something that needs to be done, it’s likely going to be a slow process because the developers need to spend time to figure out which knob to turn and how that’ll affect the rest of the code base. Hopefully this gives you a bit of clarity on optimization issues.

Whenever I select an object that has a huge amount of polygons, Blender stutters.

Multithreading is often easier said than done, because to multithread a task means finding a way to divide it into little chunks that can be done in parallel. Even then, your mileage could vary as there will be cases where the CPU has to wait for all cores to finish before moving to the next instruction. To maximize all cores only gets harder when a processor gets more of them, as what works for 4 cores can not always scale up to 8 or 16 cores.

In addition, multithreading a task is not the only way to optimize code, Blender has many areas which would benefit greatly just by improving the algorithms used along with the removal of redundant steps (ie. unneeded conversions, acceleration trees vs. simple for loops, ect…).

Yeah, I think the developers are aware of that, and I wouldn’t be surprised if they’re working on solutions to that. The thing that could potentially be slowing them down is there may be many parts of the code base that’ll be affected by those changes.