We'd have to investigate what sort of parallel constructs are available (MSVC looks like it could be the problem here), but it's an option.

C++17 std::for_each with std::execution:par is probably the best choice. It looks to be available in MSVC too.

It'd require bumping our MSVC version which historically has been a problem. Definitely solvable, just needs time and effort.

@baryluk if you wanted to prove the concept and report back any performance improvement, that would be awesome. We can decide on which parallel construct is best, or what MSVC version may be needed once there is a demonstrated improvement.

This is not parallel, but it does confirm that it could be run that way. Not sure what the best construct is to use, but tm could be a list/vector/etc of SSmesh objects whose count is known from surface.l.length or something like that. Not the best way to combine the lists either.

`
void SShell::TriangulateInto(SMesh *sm) {

SSurface *s;

SMesh tm = {};

STriangle *st;

for(s = surface.First(); s; s = surface.NextAfter(s)) {

    s->TriangulateInto(this, &tm);

    for (st = tm.l.First(); st; st = tm.l.NextAfter(st)) {

        sm->AddTriangle(st);

    }

    tm.Clear();

}

}
`

That this may be a performance win is still a guess on my part, I haven't done any profiling. Make a large circle and then Lathe to make a torus. Drag either the center point of the circle or change the radius with a low curve tolerance and it will slow way down. Since there is nothing difficult (like booleans) going on I assume the time is being spent in triangulating the 16 surfaces of the torus.

This is working on my parallel branch. The changes are completely local to that one function and are transparent unless you compile with -fopenmp using GCC. Other platforms should be similarly easy.

Gain is modest with many complex surfaces. YMMV

Using OpenMP seems less invasive than C++ parallel for, since it gracefully degrades (or at least I think it's graceful) on our old MSVC version, making it much easier to merge this code without having to upgrade the compiler at the same time.

We'd have to use at least MSVC 2017 to get any advantage on Windows, which we probably should because shipping an inferior version on one platform (the most popular platform, I assume) isn't good.