Ian Bicking: the old part of his blog

Re: Firsttryatgenericfunctions comment 000

'''You seem to be missing the point, by the way. If a library is trying to provide an extensible function, it's silly to make everyone monkeypatch it and disallow anybody from importing it. And, with the linear reduction in speed caused by monkeypatching, there will sooner or later be a breakeven point where the generic function is faster.'''

No. You can use a function from other modules after changing it at runtime.

'''Eventually, they'll beat even your example here, which by the way is a bit like saying, "see, I can write C code that runs faster than Python". Well, duh. Try the test with a dozen extra types added by monkeypatching (not by-hand inlining as shown), and see what the speed difference is.'''

Performance for generic functions seems to be slower until you have 40 different source files for if/else. However it is not 40 different types. If you put the rules in less source files, then it is lots quicker still. From my tests the break even point if they are in the same file, would be about 1000 rules. With psyco, the break even point for if/else would be 120 source files... not that I tested it with 120, just that the performance behaviour is consistent with this when using 40.

So generic functions need to be optimized for those cases where you do not have 40 different source files. Otherwise the claim of better performance can not be made. I can't think of a real life example where people actually have 40 different source files for these types of rules, but I'm sure there are cases. The other place where generic functions are faster is if you make lots of duplicated slow rules.

For simplicity of reading, sit ten random python programmers in front of the two examples, and see which one is understood more easily.

For simplicity of debugging, try debugging your C code compared to some if/else rules written in python.

I think if people understand generic functions, and if there are lots of rules that can not be kept in the same place, then they would be easier to maintain.

Thanks for pointing out why generic functions are useful. It has been interesting playing around with them. I hope I have helped you see some reasons why they are not useful.

Comment on Firsttryatgenericfunctions comment 000
by Rene Dudfield

Comments:

"""Performance for generic functions seems to be slower until you have 40 different source files for if/else."""

Not true - see my test results below. Adding just two monkeypatches to your hand-tuned jsonify brings your benchmark down to being 50% slower than the generic function version.

# Phillip J. Eby

Oops. I mean 35% slower. I was looking at 2.xx vs 3.xx without including the 'xx's in the division. :)

# Phillip J. Eby