Maarten Breddels

The ipywidget tests fail, since it adds `_comm_default` at runtime, https://github.com/jupyter-widgets/ipywidgets/pull/3590 fixes that and is also a better method anyway. The question is, is this a breaking change? I don't...

I have another commit that gives a good performance win in a situation where a lot of default are 'static' (like a fixed default value for string and ints). This...

I've been benchmarking this with pytest-benchmark using this script: ```python from traitlets import HasTraits, Int, Unicode class SingleTrait(HasTraits): foo = Int() class ManyTrait(HasTraits): foo0 = Unicode("foo0").tag(sync=True) foo1 = Unicode("foo1").tag(sync=True) foo2...

I noticed that ae8c6cde983a689602f747932f55fa3780a4a1fe slowed down the other cases because we now did some unneeded checking of presence in a dict, so I fixed that. Now ae8c6cde983a689602f747932f55fa3780a4a1fe only gives a...

Found another performance issue: We are calling `Descriptor.instance_init` for each HasTraits we create, for each descriptor, while actually many of them don't do anything. I've refactored it such that only...

After also working on the HasTrait constructor, where we remove a lot of overhead from the `hold_trait_notifications` context manager. ``` ------------------------------------------------------------------------------------- benchmark: 4 tests ------------------------------------------------------------------------------------ Name (time in ms) Min...

I think I don't see any overhead at this moment anymore at constructing HasTraits that are obvious and don't break things, I think this is as fast as I can...

> I think this warrants a bump in the model version for base and core controls to 2.1.0, right? This would signify it is backwards compatible, but that it is...

I wonder what this means for performance (having skimmed over https://v8.dev/blog/fast-async ). I might do a comparison before/after to see if it does matter.

Good idea 👍 always wanted to raise this point, I hope it's this simple though.