Speed quirk: redundant line gives six-fold speedup

[Bill Mill]

On 8/25/05, Jack Diederich <jack at performancedrivers.com> wrote:
> On Thu, Aug 25, 2005 at 09:23:09PM +0300, Stelios Xanthakis wrote:
> > The explanation is this: hash
> > and comparison of objects depends on the state of the memory
> > allocator.  A sample case is this:
> >
> >       class A: pass
> >       dummy0=47  # comment this to get a different result for min
> >       a=A()
> >       b=A()
> >       print min (a, b)
> >
> > the result of 'min' is not only non-deterministic but also depends
> > on whether other things have been allocated before.  The same
> > thing can happen for 'dictionary.keys()' if the keys are objects
> > and 'iterate-over-set' when the set contains objects.
> >

I'm also pretty sure I've caught a bug in his code, though I'm not
sure how it works exactly. I replaced the 'min' built-in with my own
min, and he's going to get nondeterministic results from this line:

       mm = min((c.S, c) for c in rowitems(h))[1].D

because 'c' is often the exact same object. A snippet from my
debugging version of 'min', which prints out the tuple its handed:

(1, <__main__.LLentry object at 0x00969710>)
(1, <__main__.LLentry object at 0x00969710>)
(4, <__main__.LLentry object at 0x00969710>)
<snip more 4s from the same object>
(4, <__main__.LLentry object at 0x00969710>)
(3, <__main__.LLentry object at 0x00969710>)
(3, <__main__.LLentry object at 0x00969710>)
(3, <__main__.LLentry object at 0x00969710>)
(2, <__main__.LLentry object at 0x00969710>)
<snip more 2s, same object>

Although they appear in order here, they don't always. Often, multiple
objects have a value of 1, and he's going to get one of them at random
as the 'min' object. I'm pretty sure.

Mark, can you confirm that this is/isn't a bug?

(btw, it still runs fast with and slow without the dummies with my
custom min() func)

Peace
Bill Mill
bill.mill at gmail.com