Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed up on_trait_change, part II #1491

Merged
merged 4 commits into from
Aug 9, 2021
Merged

Speed up on_trait_change, part II #1491

merged 4 commits into from
Aug 9, 2021

Conversation

mdickinson
Copy link
Member

Context: This PR follows on from #1490. It's part of a larger effort to identify and ameliorate performance bottlenecks in the on_trait_change, while not changing the on_trait_change behaviour.

This PR changes the way that ListenerItems are initialised. Previously, in the on_trait_change method:

  • a ListenerParser created a tree of ListenerBase instances (ListenerItems and ListenerGroups),
  • then the handler, wrapped_handler_ref and dispatch traits were set on the root node of the tree
  • and static trait-change handlers took care of propagating those changes down the tree

Those static trait-change handlers are one cause of slowness in a large Traits-using system.

With this PR, the ListenerParser takes care of provisioning all the ListenerItems at creation time, instead of propagating the changes down after ListenerItem creation.

This PR gets us partway to making the ListenerItem and ListenerGroup classes not need to be traited classes at all. I plan to make at least one more PR to complete that process.

This PR should be reviewable commit by commit: all tests should pass at each commit.

@mdickinson mdickinson added the topic: on_trait_change performance Effort to speed up the on_trait_change machinery (without changing behaviour) label Aug 9, 2021
Copy link
Contributor

@rahulporuri rahulporuri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes LGTM with one question.

Comment on lines +2675 to 2677
type=lnw.type,
priority=priority,
deferred=deferred,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not make the same changes to these three traits as well? Is that planned in a subsequent PR? type and deferred don't seem to have any static trait change handlers hooked up to them but priority does.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subsequent PR. For type and deferred, it's messy, as you'll see when the next PR lands. :-) priority is mostly the same as in this PR, except that it's handled differently at ListenerGroup level.

@mdickinson mdickinson added component: core Issues related to the core library type: performance Issues related to speed or memory usage labels Aug 9, 2021
@mdickinson
Copy link
Member Author

@rahulporuri Thanks for reviewing! Will merge this PR and then merge the main branch into #1492.

@mdickinson mdickinson merged commit bc4f1b1 into main Aug 9, 2021
@mdickinson mdickinson deleted the perf/on-trait-change branch August 9, 2021 12:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: core Issues related to the core library topic: on_trait_change performance Effort to speed up the on_trait_change machinery (without changing behaviour) type: performance Issues related to speed or memory usage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants