[Bf-committers] Performance of modifiers

[Patrice Gmail]

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