efcore: .NET Native: optimize code + native toolchain causes runtime exceptions
Scenario
Compiling a UWP app with both the .NET Native toolchain and code optimizer can cause runtime errors for apps using EF Core 1.0.0. This issue appears most on ARM devices, and are manifest in a variety of runtime exceptions.
Workaround
Opt-out of the code optimizer. As suggested in a few places (https://github.com/Azure/azure-mobile-services/issues/890#issuecomment-230610187 and https://github.com/aspnet/EntityFramework/issues/6027#issuecomment-237884929), runtime directives (rd.xml) can be used to exclude parts of code from the optimizer by adding the DoNotOptimize="true" DoNotInline="true" properties.
Example:
<Assembly Name="SomeAssemblyNameWithoutExtension" DoNotOptimize="true" DoNotInline="true" />
The .NET Native team is currently investigating a fix. TFS #248588
cc @DamirLisak @ViktorBergman @nicojmb @mattwhilden
For triage: we could consider adding the DoNotOptimize=“true” property into our rd.xml files, but before we do we should investigate the perf implications.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 53 (6 by maintainers)
Have you tried using sqlite-net instead?
OK. There are some updates on issue #7597 with the suggestion that it was the Microsoft.NETCore.UniversalWindowsPlatform needed to be updated to 5.3. This appears to have solved the issue for me.
My problem is solved now. I used Microsoft.NETCore.UniversalWindowsPlatform 5.2.2 instead of 5.3.0. See https://github.com/aspnet/EntityFramework/issues/7597
Wau, that sounds like a huge app!
Sadly, I’ll chime in with you on UWP not being ready. We’re in the same boat with a serious LOB app that uses EF Core, Reactive UI, Automapper and Sharepoint CSOM. It was basically ready 6 weeks ago in debug, but we’ve been chasing .NET native AOT bugs (and UWP bugs) ever since. It’s more or less in a usable state now, but in .NET native mode it’s by far slower than in JITted form in debug mode, even on the device.
Now in hindsight, it probably wasn’t smart to use 3 technologies (EF Core / Linq, Reactive UI, Automapper) that rely heavily on reflection (and Reflection.Emit / Expression.Compile) on a platform like UWP but coming from the full .NET framework I’ve got a feeling that we stepped back into the dark ages and have thrown the baby out with the bathwater.
The assumption that JITted code is slow and unsafe and therefore be banned from UWP apps might be a fair one, but then be consistent with it and abandon reflection and everything that depends on runtime code generation altogether. However now with the half baked solution of interpreting expression trees and using runtime directives to control RTTI it has become a big slow unstable mess.
More worryingly you only are going to find out about these problems when you run your application in release mode, something you desperately try to avoid during development because of the abysmal performance of the .NET native compiler toolchain (5GB memory usage over a few 32bit processes, 30+ minute compile times and regular OOM’s).
The only bright side I see is that the customer considers switching to iOS or Android devices because of dropping market share of Window mobile 10 and the lack of announced devices from MS. With Xamarin and our final architecture I think we’re in a good position to switch to iOS and Android easily, now that we’ve eliminated most of the AOT gotchas that probably would bite us on those platforms as well.
It’s irony I guess that JIT in the javascript world is gaining traction with V8 and Chakra and on the other side is completely abandoned in the .NET world. I thought it were exiting times because finally power of expression and development speed (closures, higher order functions, Linq, whatever) were available with reasonable runtime performance because of JIT compilation. I guess I was wrong.