Hello! I work on the .NET Native runtime and compiler team and we've recently had some reports about folks using MvvMLight on UWP and having a pretty non ideal time. The root cause of the issue is that lookups from delegates to their corresponding MethodInfos are horridly slow on .NET Native (think 10,000x slower).
We intend to get a fix for this into a future release of UWP tools but, in the mean time, it may benefit everyone if there was a mitigation placed into MvvMLight itself. The cases of this that we've seen would be greatly benefited by a small cache (10?) of these mappings but I must admit I have no hard data for how that should actually be tuned.
I'll probably have time later this week to investigate what that looks like. Let me know if you have other questions or concerns.
Comments: Hi Matt, Sure, it shouldn't be a problem to add a fix like that. Does it make sense to add it for every version of just for .NET native? Please let me know what you need me to do, and I'll do it. For info, I am working on V5.3, ETA for the release is mid-to-end of April. It would be great if we could have the fix in there. Thanks Laurent
We intend to get a fix for this into a future release of UWP tools but, in the mean time, it may benefit everyone if there was a mitigation placed into MvvMLight itself. The cases of this that we've seen would be greatly benefited by a small cache (10?) of these mappings but I must admit I have no hard data for how that should actually be tuned.
I'll probably have time later this week to investigate what that looks like. Let me know if you have other questions or concerns.
Comments: Hi Matt, Sure, it shouldn't be a problem to add a fix like that. Does it make sense to add it for every version of just for .NET native? Please let me know what you need me to do, and I'll do it. For info, I am working on V5.3, ETA for the release is mid-to-end of April. It would be great if we could have the fix in there. Thanks Laurent