anytrait: evaluate performance consequences of using per-trait listeners instead of per-object listeners

[mdickinson]

The filtered trait mechanisms in the observe framework (and in particular the anytrait special case introduced in #1496) register listeners on a per-trait basis.

This is in contrast to the on_trait_change "anytrait" handling, which registers listeners on a per-object basis.

It would be worth analysing the consequences of this choice on performance and deciding whether there's a performance case for looking at migrating the filtered trait observers to use the object-based notification.

[mdickinson]

Hmm. The on_trait_change behaviour is less clear cut than I thought:

For example, after:

from traits.api import HasTraits, Int, Str


def print_event(obj, name, old, new):
    print(obj, name, old, new)


class A(HasTraits):
    foo = Int()

    bar = Str()


a = A()
a.on_trait_change(print_event, "anytrait")

We have:

>>> a._notifiers(False)
[<traits.trait_notifiers.TraitChangeNotifyWrapper object at 0x10d4b6d90>]
>>> a._notifiers(False)[0].handler  # double check that the handler is what we think it is
<function print_event at 0x10d40f0d0>
>>> a.trait("foo")._notifiers(False)

So we've registered an object-level handler for a, but no trait-level handlers.

But if instead we do this:

>>> a.on_trait_change(print_event, "+")

Then we register on a per-trait basis instead of a per-object basis:

>>> a._notifiers(False)
>>> a.trait("foo")._notifiers(False)
[<traits.trait_notifiers.TraitChangeNotifyWrapper object at 0x10d983f10>]
>>> a.trait("bar")._notifiers(False)
[<traits.trait_notifiers.TraitChangeNotifyWrapper object at 0x10d983f40>]

The _anytrait_changed handler also appears to register on a per-trait basis rather than a per-object basis.

[mdickinson]

Not for this release.