From a glance generally looks fine. Is the peak memory usage stays the same?

Please run clang-format on the patch.

Is the peak memory usage stays the same?

How can I measure that?

How can I measure that?

You analyse the algorithm. Are there extra allocations to main per-thread contexts? Things like this.

Also, now after re-reading the description there are even more questions. From my understanding the timing is breaking down as following:

• 11 sec to dissolve vertices.
• 0.36 sec to extra grid data
• 3.5 sec to do something else
• Total is 16 sec

Almost as if it doesn't worth adding threading complexity and the actual work is to be focused in the hotspot.
But since the work is done already, I don't mind if this code is threaded. Maybe double-check with @Brecht Van Lommel (brecht).

In D8774#214555, @Sergey Sharybin (sergey) wrote:

But since the work is done already, I don't mind if this code is threaded. Maybe double-check with @Brecht Van Lommel (brecht).

I don't mind having this multithreaded.

If I add const to the vertex maps in the struct there is a warning in multires_unsubdivide_vertex_maps_free, is this ok?

In D8774#215158, @Pablo Dobarro (pablodp606) wrote:

If I add const to the vertex maps in the struct there is a warning in multires_unsubdivide_vertex_maps_free, is this ok?

Oh, well. No, warning is no good.

I still think we should have const qualifier for data which is not supposed to be modified after initialization. But then the "legacy" semantic of C style free gets in a way. I think is better to keep const and cast it away in the MEM_freeN() call. In a longer term maybe even use const void* in the MEM_freeN() function. This will be more intuitive with C++, where

const int* a = new int[10];
delete[] a;

is an absolutely valid code.

@Brecht Van Lommel (brecht) , @Sybren A. Stüvel (sybren) what do you think?

In D8774#215205, @Sergey Sharybin (sergey) wrote:

Oh, well. No, warning is no good.

I agree.

I still think we should have const qualifier for data which is not supposed to be modified after initialization.

I also agree here.

But then the "legacy" semantic of C style free gets in a way. I think is better to keep const and cast it away in the MEM_freeN() call. In a longer term maybe even use const void* in the MEM_freeN() function. This will be more intuitive with C++

Such a cast should IMO be accompanied by a comment that explains why it's okay, as generally you don't want to cast constness away. I'd be fine with changing MEM_freeN() to get const void*.

The patch description reads:

On a Threadripper 3990X, this loop goes from 0.369013 to 0.017537

Always include units with the numbers (unless they are actually unitless).