I've done some performance analysis on our CM-based solution and view location in a viewmodel-first often rises to the top of a hotspot analysis. The problem is predominantly the O(n2) join on exported types from the assemblies in
. Since the performance was problematic for our application, I needed to improve it.
The first problem I encountered is that the logic to select types from names is tightly bound within the
method. After the generation of view type names from viewmodel type names in
, it seems natural to break out the discovery of types by name into another extension point, so I created
. This would allow me to create some kind of caching mechanism on type names so I don't need to keep hitting the tight join on
, I started caching types by name in a
. This mostly worked but if the cache started empty, I still had to hit
at least once for each view type. If I pre-populated the cache with all exported types from
the cache size was large (16,000+ entries) and I imagine this would put undue pressure on memory constrained devices. After a few rounds of measuring and adjusting, I think I found a happy midpoint in caching custom derived
eagerly on cache creation with a single call on
. This results in a 300+ entry cache which, considering an average type name length of 40 characters is ~5000 bytes - a reasonable cache size for everything except smart watches (which CM doesn't run on, yet!). The load time for the initial
cache creation turned in times 50% faster and subsequent calls to
didn't even register in the profiler's hotspot analysis after this change.
I committed this code to a branch on my fork for any review before I make a push request.