[Python-Dev] Silly little benchmark
Sat, 14 Jul 2001 18:39:25 -0400
> Here's a patch to abstract.c that does to binary_op1() what I had in
> mind. My own attempts at timing this only serve to confuse me, but
> I'm sure the experts will be able to assess it. I think it may make
> pystone about 1% faster.
I would have tried this in PyNumber_Add instead (which pystone never enters!
it doesn't do any string cats, and all its adds are integer adds
special-cased away by BINARY_ADD).
binary_op1() is entered often by pystone, but only for int * and /, and
(just) a few times each for float subtract and the one-shot
Array1Glob = *51
Array2Glob = map(lambda x: x[:], [Array1Glob]*51)
module initialization lines. So adding an early-out in binary_op1()
"should" only harm pystone. Adding an early-out in PyNumber_Add instead
should be neutral for pystone (but should slow, e.g., floating-point code a
> Note that this assumes that a type object only sets the
> NEW_STYLE_NUMBER flag when it has a non-NULL tp_as_number structure
> pointer. This makes sense, but just to be sure I add an assert().
> In a bizarre twist of benchmarking, if I comment the asserts out,
> pystone is 1% *slower* than without the patch.... I guess I'm going
> to ignore that.
Is the Unix build such that release mode doesn't manage to disable asserts?
I wouldn't ignore this, because the source code the C compiler sees in
release builds *should* be the same as if the assert lines had been
lines instead. I don't see anything in the non-Windows builds that's
#define'ing NDEBUG in release builds, which is what they have to do to turn
Note that I understand that the effect of an assert "should be" to slow
things down, but that you're seeing it slow down when they're commented out.
That's not what I'm pursuing in this part: I'm wondering why you see *any*
difference when commenting out asserts, regardless of direction. You
shouldn't, and since I don't see anything that ever turns asserts off except
in the Windows build, that makes me twice as suspicious.