Inherited attached properties performance impact?

[stevemonaco]

Looking for some insight on the performance cost of inherited attached properties in Avalonia for seldom changed properties. I have a few scenarios which would simplify some difficult wiring problems in maybe half a dozen properties. They need to be usable for bindings, so I can't reasonably use resources. Examples:

• Full/compact size (updated based on main view size breakpoints)
• Parent (scoped) navigation/dialog container
• Navigation capabilities: CanGoForward / CanGoBackward

There aren't many inherited attached properties in Avalonia (a few on TextElement). Obviously, the more subscribers that do work on the property change, the more impact. So the question is really: how much performance impact do inherited attached properties add as the control tree size grows?

[StefanKoell]

I can only share my experience with 4 inherited attached properties in my app. I recently came across a fairly huge performance issue (#18488) and while troubleshooting it, I also removed my 4 inherited attached properties to see if it was causing the issue or making it worse. In my app, there was no measurable performance hit using those 4 inherited attached properties. The complexity of my app (number of elements in visual tree) was high enough to hit the referred performance issue.

But I'm also curious if there's some "guidelines" or recommendation on how many of these inherited attached properties are too many.

[stevemonaco]

I did some testing (and source reading) over the weekend and it seems like there is a virtual tree created and maintained with only from interested objects. So the impact should be incredibly minimal in my cases: few setters, few listeners.