Matching performance

[deanWombourne]

SwiftUI reloads its view hierarchy a lot. This wasn't a problem when we used the previous matching scheme because all the heavy lifting was done when a style was added, not when a style was requested.

With NDS, we can't take any shortcuts when we add a style so all the matching has to be done when a style is requested - and the matching is heavier than before as we have to compare every style and sort, whereas previously we just found the first match and used it.

Are we concerned about matching performance? If so, should we add in some sort of matching cache so we don't recalculate matching scores for identifier pairs we have matched before.

Minimum, should we add in some metrics so we can at least know what effect matching is having (i.e. metrics like total matches, total time spent matching, average time per match etc)? If we do this, we might find out that I'm worrying over nothing :)

[kerrmarin]

Great idea -- we've not seen any noticeable performance penalties after moving to NDS but I think it would be a great little win to cache the results of a match. In general, most styles are created at the beginning of the app's lifetime but the styles can be modified at any point so I guess we'll have some decisions to make regarding invalidation or updating already cached results.

[kerrmarin]

This was addressed in 46f00dc

[deanWombourne]

Odd question about that commit (and the stylist in general) - do we care about multithreading, and if so, should we care about this being an actor?

[kerrmarin]

Hasn't been a problem so far, but probably wouldn't hurt to make it thread safe 🤷

[deanWombourne]

#52 ;)