Wow. Can you possibly be more negative?
I think it's worse to give the poor guy the run around
by making him run lots of random benchmarks. In
the end, someone will run a timeit or have a specific
case that shows the full effect. All of the respondents
so far seem to have a clear intuition that hook is right
in the middle of a critical path. Their intuition matches
what I learned by spending a month trying to find ways
to optimize dictionaries.
Am surprised that there has been no discussion of why
this should be in the default build (as opposed to a
compile time option). AFAICT, users have not previously
requested a hook like this.
Also, there has been no discussion for an overall strategy
for monitoring containers in general. Lists and tuples will
both defy this approach because there is so much code
that accesses the arrays directly. Am not sure whether the
setitem hook would work for other implementations either.
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
If my thoughts on the subject bug you, I'll happily
withdraw from the thread. I don't aspire to be a
source of negativity. I just happen to think this
proposal isn't a good idea.
Raymond
----- Original Message -----
From: "Guido van Rossum" <gu...@python.org>
To: "Raymond Hettinger" <pyt...@rcn.com>
Cc: "Thomas Wouters" <tho...@python.org>; "John Ehresman" <j...@wingware.com>;
<python-dev@python.org>
Sent: Thursday, April 02, 2009 2:19 PM
Subject: Re: [Python-Dev] PyDict_SetItem hook
Wow. Can you possibly be more negative?
2009/4/2 Raymond Hettinger <pyt...@rcn.com>:
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/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
