Hello, I spent some time running performance tests on a few modifiers. My original goal was to see if the "noise modifier" was doing reasonably well. But I think some results are worth sharing, and bring some worthwhile considerations - although it may be that these are known facts to most developers, you tell me.
Test uses a single 1000 vertices mesh object (a 40 x 26 UVSphere), that is first modified by an array with count 100, so that subsequent modifiers have 100 kV to handle. Time is measured with TIMEIT_BENCH, calling PIL_check_seconds_timer(), inserted at modwrap_deformVerts() so as to catch all deform Modifiers in the same fashion. Here's what I get: Array Modifier 1,22 Noise Modifier - Vertex mode 0,0031 Noise Modifier - Loose parts no pivot 0,0055 Noise Modifier - Loose parts pivot 0,0064 Displace - No Texture 0,002 Displace - Default Texture 0,022 SimpleDeform - Twist 0,0036 Latice 0,038 Shrinkwrap - OMP 4 threads 0,008 Shrinkwrap - OMP OFF 0,026 Do some of you have similar measurements that I could compare with ? If yes, would they corroborate or be different ? What's interresting to note is that: - Array Modifier is a couple of hundred times more expansive than the typical deform modifier. It being more costly is no surprise, but the ratio is still impressive. - Array Modifier is called every single time. If I just change the seed of the noise modifier or the strength of the displacement that's down the stack, this triggers another run on the super costly array modifier. It seems this is not always necessary. - Displacement modifier with texture is about 10 times slower than the more basic modifiers, but still among the good performers. - Shrinkwrap is one of the very few modifiers that benefits from omp, and the gain is impressive (it seems to be more than /numthreads, but that is probably an artifact). With 8 ms to process 100 kVertices, shrinkwrap is among the fastest modifiers, although its work is not trivial. - It seems it could be a good idea to launch an overall parallelization of modifiers task. Could it have been a GSOC project ? Certainly an interresting endeavor. I'm willing to participate. - Although a x4 (or more, depending to cores) gain in deform modifiers would be appreciated, the most critical work would be on the most costly constructive modifiers, even though introducing parallelism is likely to be more touchy. I'd be happy to get your thoughts on this. Patrice _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
