I check out trunk at revision [4101], before the property changes were introduced, as old_trunk and run setup.py test.

(misc)old_trunk/ time python setup.py test 2> /dev/null 
running test
...

real	2m57.447s
user	2m55.135s
sys	0m1.952s

I then run setup.py test on the latest revision of trunk@[4160], which includes all property implementations aside from those in fipy.terms.

(misc)trunk/ time python setup.py test 2> /dev/null 
running test
...

real	3m0.290s
user	2m57.987s
sys	0m2.000s

There's only a three second difference between the two; clearly not a big deal.

How about a non-trivial benchmark like phase anisotropy? For this, I copy-script'd the anisotropy example from examples.phase, then stripped out the viewing code and reduced the number of steps to one hundred.

I then ran it on trunk@[4101], without the properties:

(misc)old_trunk/ time python phaseAnis.py 
...

real	3m50.701s
user	2m50.679s
sys	0m59.748s

And then on the current trunk@[4160], with properties:

(misc)trunk/ time python phaseAnis.py 
...

real	3m49.818s
user	2m50.455s
sys	0m59.104s

Again, we see a negligible difference (3:50 vs. 3:49) between the two runtimes. These two trials have convinced me that the property refactoring hasn't added any considerable computational burden.