[Python-Dev] PyDict_SetItem hook

Fri Apr 3 22:36:57 CEST 2009

On Thu, Apr 2, 2009 at 5:57 PM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Apr 2, 2009 at 3:07 PM, Raymond Hettinger <python at rcn.com> wrote:
>>> Wow. Can you possibly be more negative?
>>>> I think it's worse to give the poor guy the run around
>> Mind your words please.
>>> 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.
>> I may be partially to blame for this. John and Stephan are requesting
> this because it would (mostly) fulfill one of the top wishes of the
> users of Wingware. So the use case is certainly real.
>>> 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.
>> The primary use case is some kind of trap on assignment. While this
> cannot cover all cases, most non-local variables are stored in dicts.
> List mutations are not in the same league, as use case.
>>> 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.
>> I don't actually believe that you can know whether this affects
> performance at all without serious benchmarking. The patch amounts to
> a single global flag check as long as the feature is disabled, and
> that flag could be read from the L1 cache.

When I was optimizing the tracing support in the eval loop, we started
with two memory loads and an if test. Removing the whole thing saved
about 3% of runtime, although I think that had been as high as 5% when
Neal measured it a year before. (That indicates that the exact
arrangement of the code can affect performance in subtle and annoying
ways.) Removing one of the two loads saved about 2% of runtime. I
don't remember exactly which benchmark that was; it may just have been
pybench.
Here, we're talking about introducing a load+if in dicts, which is
less critical than the eval loop, so I'd guess that the effect will be
less than 2% overall. I do think the real-life benchmarks are worth
getting for this, but they may not predict the effect after other code
changes. And I don't really have an opinion on what performance hit
for normal use is worth better debugging.
>> 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.
>> I think we need more proof either way.
>>> Raymond
>>>>>>>> ----- Original Message ----- From: "Guido van Rossum" <guido at python.org>
>> To: "Raymond Hettinger" <python at rcn.com>
>> Cc: "Thomas Wouters" <thomas at python.org>; "John Ehresman"
>> <jpe at wingware.com>; <python-dev at 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 <python at 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 <jpe at 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