The measurements are just a distractor. We all already know that the hook is
being added to a critical path. Everyone will pay a cost for a feature that
few people will use. This is a really bad idea. It is not part of a thorough,
thought-out framework of container hooks (something that would need a PEP at
the very least). The case for how it helps us is somewhat thin. The case
for DTrace hooks was much stronger.
If something does go in, it should be #ifdef'd out by default. But then, I
don't think it should go in at all.
Raymond
On Thu, Apr 2, 2009 at 04:16, John Ehresman <j...@wingware.com> wrote:
Collin Winter wrote:
Have you measured the impact on performance?
I've tried to test using pystone, but am seeing more differences between
runs than there is between python w/ the patch and w/o when there is no hook
installed. The highest pystone is actually from the binary w/ the patch, which
I don't really believe unless it's some low level code generation affect. The
cost is one test of a global variable and then a switch to the branch that
doesn't call the hooks.
I'd be happy to try to come up with better numbers next week after I get
home from pycon.
Pystone is pretty much a useless benchmark. If it measures anything, it's the
speed of the bytecode dispatcher (and it doesn't measure it particularly well.)
PyBench isn't any better, in my experience. Collin has collected a set of
reasonable benchmarks for Unladen Swallow, but they still leave a lot to be
desired. From the discussions at the VM and Language summits before PyCon, I
don't think anyone else has better benchmarks, though, so I would suggest using
Unladen Swallow's: http://code.google.com/p/unladen-swallow/wiki/Benchmarks
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
