Hi.
*Decimate modifier.
*Freestyle
*Rigid Body simulation
*Also the process for assigning Rigid Body from active to many converted particles/objects. When you select the converted particles/objects, then you assign Rigid Body to the active one, and then with all selected you select “Object > Rigid Body > Copy from active” (Probably copying any attribute from active to many objects is single thread process)
Hi @easythrees,
Would you be interested in contributing to Blender development, or is this a question you’re asking as a user?
Edit Mode in general, I’m not sure if it’s multithreaded at all, high count meshes are impossible to deal with in Edit mode
Also, multithreading code isn’t that simple or easy. We tend to look at that as an easy solution that fits all purposes and fixes everything. I know I used to.
Thing is that multithreading adds overhead, splitting tasks into threads and then sending those to the cores has a lot of overhead, there isn’t an automatic way to do it, the coder must deal with that. When tasks are very easy to parallelize and take a lot of time (example, rendering tiles) then the overhead is negligible and the benefits of multithreading are very obvious.
But when tasks are smaller, faster and you must work around them to parallelize… the overhead eats up any benefits and multithreading becomes a burden.
If it was that easy, everybody would do it everywhere, and truth is it doesn’t happen that much. Games have just started parallelizing stuff since those now use multiple passes for rendering frames after geometry is processed, and you can parallelize those passes, but without those… you’d be stuck on single threads as it’s always been the case.
Hi @MetinSeven, I’ve actually made a contribution to Blender, I’m looking to make more. I work at AMD and my group works with software vendors to help improve their software’s performance, hence the question.
I would add two things:
PS:
.blend file compression is in development already:
That’s great, didn’t know that! Keep up the good work!
I would say modifiers, there are some benchmarks out there that compare several DCCs, Blender included and one of the tests is using a bend modifier on a 3M poly dragon scan model and Blender is terribly slow, around a couple FPS where Maya and Max are more than 10x faster.
The use case of a 3M poly model is obviously to make the differences more obvious, lower density models also show a big difference.
Not sure if its a multithreaded issue or just lack of plain optimizations, but im sure if it gets multithreads on the modifiers, even gpu acceleration, it would make a major difference
BMesh needs updating to multi-threading, particularly to speed up Sculpt Mode’s Dyntopo mode, but the original BMesh developer is already taking care of this:
There are a couple slow things in the VSE you can easily try, all starting from “File > New > Video Editing”.
Drag a 1080p H.264 video clip onto the timeline and try to play it. Even though your computer can probably play the file fine, performance in the VSE tends to be much slower. Add a transform or effect and it can often drop into single-digit FPS. The “Prefetch frames” feature that generates cached previews could probably be parallelized.
Put some video clips on the timeline and export. You will see that the CPU usage (as measured by top) doesn’t go over approximately 120%, but the VSE could probably render multiple frames in parallel. I’m guessing this is not a trivial modification because some things work best sequentially (decoding source video, encoding output video).
multithreaded bmesh would increase perf for many popular addons as well
I don’t know if this is a multithreading thing but polypainting on heavyer meshes seems to be pretty slow for me.
There’s a lot of great suggestions here, I’ll start a google doc so that we can also record details. Keep the suggestions coming please 
Polypainting is to be redone. There’s in the works a patch that increases performance a huge lot, but was pulled off the master branch due to some problems that need solving, but was indeed a lot faster, I am sure we’ll have news about it sooner than we expect.
Editing high poly meshes in general is very slow. It was on the roadmap for 2020 but seems to have stalled a bit.
Multi-Thread bmesh to mesh conversion is one of the big targets for Milestone 1 I believe:
Other than that, making the modifiers (like decimate and remesh) faster would also be really nice, especially relevant now with the geometry nodes projects.
Awesome! Good to know. 
I have no problem switching to ZBrush for that but if I have the option to do it in Blender and just as good: Rock and roll! 
Cloth sim could be improved a lot because it’s completely single-threaded right now AFAIK.
I’m not sure why I thought this was a multi-threaded simulation. You are right, this is single thread.
Yes, some of it is multithreaded. The last thing I did in that regard was multithreading collision detection, along with other improvements and optimisations. More recently, other people (@mano-wii @angavrilov) have also made further optimisations.
There are still some parts that could be multithreaded, but the gains would be small at this point. Multithreading is not a magic solution that you just slap on top of inefficient code, suddenly making it super fast. I haven’t profiled the cloth code in a while, but off the top of my head, the slowest step right now is the linear solver itself, which can’t really be multithreaded. And the parts that can be multithreaded probably wouldn’t benefit from it, as they are already pretty quick.
Keep in mind that multithreading very small and quick operations can actually make the code slower, as just the thread initialisation can actually take longer than the operation it’s executing.
The cloth engine in Blender is reaching its limits. We’re just pushing diminishing returns at this point. What we need for faster and better simulations, are better algorithms. Blender’s cloth implementation is almost 15 years old now, with a bunch of different stuff getting bolted on top over the years, and while some parts have been rewritten, it is fundamentally still the same as 15 years ago.
There have been plenty of developments in the research community over these 15 years, and there is plenty of good stuff to implement now. But I’m afraid that it would be a rather major endeavour. We really are running out of low hanging fruit here. Multithreading is not the solution.