Efcore: .NET Native - Perf: LINQ queries run slower on Release mode

[abdu292]

Friends,
I was doing some performance testing before I publish the app on to the store. However here is one critical issue I am seeing.

The below code takes around 8 second to run in Release mode, but runs within just 2 seconds in debug mode.
(where the related tables are very small tables and the number of records in the main table is 150)

If the code runs within 2 seconds in debug mode (with debug overhead), I would expect to run this within milliseconds in release mode. If I double the records (150=>300), the amount of time it takes also doubles (as one would expect). I know from the docs using Anonymous LINQ query can result in poor performance in RC1, and I believe it is fixed in RC2. Even it did not, wondering if the "Include" comes under this category, and this is the reason for the performance issue. If so, do we know how we can refactor the "include" that gives me better performance (may be more than debug)?

public async Task<IList<Student>> GetStudentsAsync()
{
var students = await _context.Students
.Include(b => b.Addresses)
.Include(b => b.Emails)
.Include(b => b.Titles)
.Include(b => b.Phones)
.Include(b => b.Websites)
.ToListAsync();

return students;
}

I am using Visual Studio 2015, UWP 5.1.0, Native Tools 1.3.1, Entityframework Core RC2 and SQLite.

[ErikEJ]

This will load all data from all tables?

[abdu292]

@ErikEJ Yes, it does and that is part of the requirement. Those tables are very tiny.

[divega]

Since you say the query executes much faster in Debug than Release mode and yours is a UWP application, I believe this might be due to a performance limitation in the way .NET Native applications execute in-memory compiled LINQ expressions (which is a mechanism EF Core uses a lot):

Expressions don't actually get compiled into IL and then translated to native code by a JIT compiler as would normally happen in a non-native .NET application (because there isn't a JIT compiler when executing a .NET Native app) so they are interpreted instead.

Depending on what the slowest part is, a possible workaround would to execute multiple individual queries, e.g.:

C# public IList<Student> GetStudents() { _context.Addresses.Load(); _context.Emails.Load(); _context.Titles.Load(); _context.Phones.Load(); _context.Websites.Load(); return _context.Students.ToList(); }

Note that:

1. I am assuming that this query is supposed to load every row from these tables into memory. Assuming the query results are tracked by the context (they are by default) the relationships will get fixed up in-memory and Student instances will get their navigation properties populated.
2. There is actually no advantage in using async the way you were using it your code with the SQLite provider. SQLite does not do async I/O, and we don't try to do any kind of compensation for that in either our ADO.NET provider or EF provider. If you want the whole loading of this data to happen in a different thread from the UI thread for responsiveness you may try explicitly doing it with something like var students = await Task.Run(x => x.GetStudents());

[abdu292]

Thank you @divega for your response.
I tried refactoring my code to load the tables individually with Load() method, and it appears that the number of seconds it takes has no much difference. If it was 8 seconds, now it is around 7 seconds. I consistently checked many times and I can see there is a one second different in the new version of code. However, from a user's stand point it is still too much.

I am using repository pattern in data layer and a service layer (initially I was using file system, and converted to SQLite, it was easy for me to do the conversion because of the Repository pattern), and yes with two different Universal Class Libraries for each layer. Do we know if these two layers of abstractions can cause this performance issue? (I tried removing the layers in debug mode and deploy on to my device and found there is no difference at all, though I did not try in release. Testing release in UWP is very time consuming as we know).

Also, thank you again for giving the information on Async with SQLite. I never knew this.
also, do you mean students = await Task.Run(GetStudents()) or Am I missing any other syntax that the Task gets contextual information and you call the method with the lamda variable like x.GetStudents()

[divega]

How many rows do these queries return from the database? Could you share the model or otherwise provide some information about the number of columns on each table and types used? Hopefully we will be able to find something in either EF Core or in .NET Native to make things faster.

Re Task.Run(), I was referring to the overload that takes a sync delegate. But I didn't actually try to compile what I wrote and most likely it was wrong: if it just takes a Func<T> the it should be var students = await Task.Run(() => GetStudents()).

[abdu292]

I have 150 records now in the main table and each related table will have 4-6 associated rows for each of those main rows.
Here is the outline of my model,

Student => 1 integer property, 5 (below) navigational properties of IList<T>, 2 string properties, 5 get only string properties which are [NotMapped], 1 DateTime property
5 Other entities (Address, Email, Website, Titile, Phone) => 2 integer properties, 1 Navigational property to Student, 1 Enum property, 1 string property (get only, that converts string to enum)

I am not sure, if it important to say here, as indicated above, all the 5 related class has a get only string property that converts the string to enum with the help of an extension method like so public static T ConvertToEnum<T>(this string enumString) => (T)Enum.Parse(typeof(T), enumString);

Yes, Task.Run accepts Func as well as Action. So we are good there. Thank you for the note!

[abdu292]

Hello Again,
FYI. I just tried removing the Enum conversion from all the five related tables and created another release package. However the performance is still the same and no noticeable impact.

[abdu292]

Here is the repro of the issue I created, if that helps to resolve the issue quickly. Thanks!

Note (Preferably, please use phone device that's where performance matters):
Try running the below in both Debug and Release modes.

1. Run the app => tap "Tap to insert" button for the first time. Please wait until the "All Done!" status (I gave 250 samples to insert as default, given all are tiny models, you may change the number using the editable box in the left)
2. Now tap "Tap to Load" button, and see the seconds it takes (milliseconds and seconds are displayed on the screen)
3. Close the app using the Bottom App bar button and repeat ONLY Step 2 again (Step one is required only once, if repeated it would double the Students count). See the seconds it takes.

EDIT : Ignore the previous attachement. Here is the updated one.
SQLitePerf.zip

@divega or others. Please let me know if you need more info. Thank you again.

[abdu292]

@divega Wondering if you got a chance to look at my comments. Thanks!

[divega]

@abdu292 I saw your comments. It will take at least a few days to evaluate if there is any short term solution to this.

[abdu292]

Great! Thank you @divega

[mvermef]

I am in a similar situation with building related to .Net Tool Chain compilation. 0.2ms versus 18.8 seconds, is the amount of time we are talking when an Include is involved... 245 rows in primary table (Hotels) and the foreign key table has about 856 rows. var hotels = Hotels.Include(h -> h.Comments);

no .Net Tool chain involved = .2ms
.Net Tool chain => 18.8 seconds.

[rowanmiller]

@natemcmaster can you get this into a format where we can hand it off to .NET Native team (talk to me or @divega)

[natemcmaster]

This slow performance is likely due to the .NET Native compiler. In UWP 1.3, the compiler added a feature called universal shared genetics. Before this, most EF queries with "include" didn't work at all. USG allows these types of queries to work, but its slow performance is a known issue. The compiler team has been working on this for a while. Obviously, it's something we hope to improve in future releases of UWP tooling.

[divega]

@natemcmaster We were suspicious that this one would actually be due to a different aspect of .NET Native: LINQ expression trees cannot be compiled into IL to be executed in memory but instead are interpreted.

In any case, we still need to put a repro together and hand it off to the .NET Native team for them to evaluate if they can improve the performance.

[abdu292]

@natemcmaster @divega Thanks for the update. However the performance is still the same if we use "Load" too. So do we know if both Include & Load are the same as to how these work under the hood?

[divega]

@abdu292 yes, ultimately most of the code is the same.

[abdu292]

@divega Okay. Thank you!

I already provided a repro in one of my previous posts. Can we leverage the same to give to the .NET Native team? I thought you all got a chance to run my repro solution.

[mvermef]

This going to be a sit and wait or is there a work around to this performance degradation, based on your comment of IL interpretation over compilation (missing jit in native) was there only solution to rush something out the door for native compilation time frame they were under? I have an idea but it's a cumbersome workaround at best, just going to be quadruple the amount of code to get the same effect. I would like to stay with EF as the orm in place since it's what I use most of the time.

[abdu292]

@natemcmaster @divega @rowanmiller With the EntityFrameworkCore RTM release date on 27th of June (in a few weeks), Would this be feasible to target resolving this issue by RTM?

[divega]

@abdu292 @mvermef the .NET Native team is aware of this issue and the repro. We haven't heard back yet from them on any recommendations to change EF Core code or possible improvements in their bits. Note that we have assigned the issue to the 1.0.1 milestone, meaning that we don't necessarily expect a fix in the RTM time frame. That said if there is anything low hanging we can tackle in the next few days, we'll try to do it.

[abdu292]

@natemcmaster @divega @rowanmiller Thank you for the update. So, Is there any APi for us to use to write raw T-SQL queries within our EntityFrameworkCore context? If no, any other work-around that you can think of (Just until this issue is resolved)? And that would enable to us to go ahead and publish our apps. Thanks!

[divega]

You can try FromSql() to run raw SQL queries, but I doubt it will give you better performance as it shares most of the same mechanics with LINQ queries for object materialization.

If I was trying to workaround this issue I would approach it by:

1. First, identifying the set of queries in the application that don't perform acceptably with the amount of data expected to be used in production (given what we know about this issue, I would expect those to be queries that retrieve relatively large numbers of rows).
2. Then, applying one of the following strategies (depending which one works best on each query):
   
   
   
   1. Reduce the number of rows retrieved: this may involve rethinking how the user interacts with the application, e.g. require the user to type a filter criteria instead of displaying the full table in a list.
   
   
   2. Retrieve the data in the background while the user can perform other actions.
   
   
   3. Use handcrafted materialization code against plain ADO.NET classes or some micro-ORM (not sure which ones currently offer UWP support) and potentially attach them to the application's DbContext.
   
   

By the way, another thing I would test is tracking vs. no tracking queries.

[natemcmaster]

Is there any APi for us to use to write raw T-SQL queries within our EntityFrameworkCore context?

@abdu292 if .FromSql doesn't work, EF provides API to expose the lower-level ADO.NET components. As @divega suggests, you can write your SQL queries directly as an ADO.NET DbCommand and execute it on the same connection DbContext is using.

c# var connection = _context.Database.GetDbConnection(); using (var command = connection.CreateCommand()) { command.CommandText = @"SELECT * FROM FooBar"; // raw SQL here // etc. Google/bing "ado.net command" to see numerous examples of how to use DbCommand }

[divega]

Thanks @natemcmaster for adding those details. You will most likely have to open and close the connection since EF typically keeps it closed until needed.

[abdu292]

@natemcmaster @divega Thank you for the information on how FromSql works and also on the ado.net. However, I spent a huge amount of time (research in release mode is time consuming and painful) to research on this and it doesn't look like data retrieval taking any time whether it is with "Include" of EF or ADO.NET APIs like ExecuteReader, etc.

The actual time consuming part is when the retrieved data maps back to the class objects. Especially it takes double the time of EF when we map the data to class models after reading the db using ADO.NET ExecuteReader. EF does a great job there.

I am wondering why this issue is closed. Is this because it should be investigated by the .NET Native team? Any response on my above comment would be much appreciated!

[divega]

Oops, I must have clicked on the close button instead of comment! 😓 Thanks for pointing it out!

The actual time consuming part is when the retrieved data maps back to the class objects

That was my expectation. The code that does that part of the work is a compiled expression.

[abdu292]

Sure. Thank you!

That was my expectation. The code that does that part of the work is a compiled expression.

Interesting. I thought it happens when retrieving the data (as we experience in the data centric apps).
And this was the very reason I asked for the api to write T-SQL (raw) queries. Nonetheless, that was a great info on how we can get connection/use command etc within ef context. I got a great hands-on while researching.

I continue asking and the next would be, is there any way I can exclude only just one method/at last a class from Native compilation (may be via Runtime Directives) and can regain the performance. I am not very much familiar with rd, but read somewhere it helps to exclude reflection based code/something similar. Thank you again!

[abdu292]

@mvermef

I have an idea but it's a cumbersome workaround at best, just going to be quadruple the amount of code to get the same effect.

Were you able to workaround on this issue? Would you mind sharing that cumbersome idea? (I tried many of them as mentioned in my previous posts, but no joy so far)

Thanks!

[mvermef]

negative workaround :(

[abdu292]

Any one feels any performance difference on this issue, with the new .NET Native Tool 1.4?

[rowanmiller]

@natemcmaster can you hand off an issue to the .NET Native folks so that they can address this

[natemcmaster]

@rowanmiller It's already been handed off (via internal msft email thread with @mattwhilden.) 😄

@abdu292 I'm not aware of any major updates to expression interpretation in .NET Native 1.4.

[MattWhilden]

Oh goodness. I agreed to take a look at this and then got pulled away on a family emergency... Consider this my public shaming and I'll push this to the front of my work queue.

That said, System.Linq.Expression are all interpreted on .NET Native and their runtime performance is general: faster if you're only calling them once or twice, slower if you're doing things in a hot loop. It's possible that there's some bottleneck somewhere we can get patched up but it'll probably need to be worked around for the time being.

[mvermef]

for what ever it is worth, Include( p => p.SomeNavigationCollection) does actually compile nicely under Release. Right now I am seeing .72ms with a GroupBy

@natemcmaster I did get it to pull that UWP 5.2 version in finally on my main desktop not sure on my Surface yet, I have a bad feeling that my install of VS 2015 might need to be uninstalled or repaired on my Surface Pro3 :( even after the Update 3 reattempt.

[MattWhilden]

If you're working with 5.2, beware the dragons:
https://social.msdn.microsoft.com/Forums/en-US/e766a904-7346-4f76-bad2-852d3b301b0e/known-issue-version-52-of-microsoftnetcoreuniversalwindowsplatform-delisted-all?forum=Win10SDKToolsIssues
We're working on getting a fixed 5.2.1 out but it's not ready just yet.

[mvermef]

Knew it was delisted but didn't realize it was that bad, knew about the clrcompression issue listed in the corefx repository. Really noticed after day 2 of release ;P

[MattWhilden]

Yep. There are workarounds you can hack into your project.json but wanted to make sure you didn't get caught by more issues.

[natemcmaster]

@MattWhilden what are the workarounds? We should to add them to the EF getting started guides.

[MattWhilden]

https://github.com/dotnet/corefx/issues/9711 and https://github.com/dotnet/corefx/issues/9743 have workarounds. Hopefully we'll get the new package out soon.

[abdu292]

@mvermef

for what ever it is worth, Include( p => p.SomeNavigationCollection) does actually compile nicely under Release. Right now I am seeing .72ms with a GroupBy

Do you mean ".Include" is performant even in release mode? Is that with UWP 5.2.0? I ask this because my "include" queries are slow (5 includes in a query and I am calling it in one shot)

[mvermef]

18 seconds was what I was getting before in release build, now its like it was in debug without native tool chain.

[abdu292]

Wow! I did not realize UWP 5.2.0 is more performant. However the existing known issues are preventing me to upgrade to it. Though there are workarounds the team doesn't encourage to upgrade at this point. Let me see if I can give it a try.

[abdu292]

I tried a release build on UWP 5.2.0 on the repro project (the project which I attached above in one of my previous posts) and here is how it looks like (no much difference, 8 seconds still too much from a user's stand point to load 150 rows)

Linq with "Include"

5.1.0 => 14544ms (14s)
5.2.0 => 8833ms (8s)

[DrewScoggins]

I am going to collect some traces and take a look at this. See if we can track down what exactly we are spending our time on.

[MattWhilden]

For those keeping score at home, Drew is a perf Dev on the .NET team so this issue has found its way out of my fumbling hands and into those of an actual expert.

[mvermef]

😆

[abdu292]

@DrewScoggins Wondering if any joy so far with this. Thanks a ton for your work on this!

[DrewScoggins]

I was able to sit down and take a look at this today, so I wanted to update this issue. I was looking at this on my dev box and not a phone, and I was only seeing a regression of about 4x between Core and .NET Native (90ms to 360ms). Since this seems quite a bit different than what you were seeing on the phone I am going to get a phone setup and take more traces there and take a look at them tomorrow.

[abdu292]

@DrewScoggins Did you get a chance to test this on a phone yet? Any hope to get this fixed any time sooner? Thanks for your effort on this!

[DrewScoggins]

I was able to get this on a phone and get a trace. I am still seeing times on the phone of about 1300 milliseconds versus 350 milliseconds on CoreCLR. The majority of that time is being spent in the interpreter running the LINQ expressions. In particular, we are spending a large amount of time getting the return type of the MethodInfo inside the interpreter. The majority of this time is being spent in TryGetNamedTypeForTypeReference. This seems like a place were we could do some caching to speed this up, but I am not an expert on reflection. Adding @MichalStrehovsky.

[MichalStrehovsky]

TryGetNamedTypeForTypeReference

Yeah, this is a linear scan of a table that maps metadata to the runtime types that exist within the system. It wasn't expected to become hot, but since MethodInfo doesn't cache the return parameter (and the way ReturnParameter is implemented actually _hits the slow method for each parameter, and then throws everything but the return parameter on the floor_), this became hot.

There are two things we can do:

1. Get rid of the linear scan. We should be able to replace it with a hash table. I already have a bug tracking this internally, it just never was high pri enough. I'll make it higher pri.
2. If things are still not fast enough, add a cache for MethodInfo so that we don't recompute everything all the time. At minimum, split the return parameter from other parameters.
3. If things are still not fast enough, add a cache to the LINQ interpreter.

I would be really happy if 1 solves it completely because 2 and 3 would cause a regression in working set.

Unfortunately, I can't share any timelines as to when an update of .NET Native with this would be available, and no workarounds come to my mind.

[popcatalin81]

@MichalStrehovsky There's no reason to have linear scans anywhere in the EF metadata, because you will hit client a scenario with performance issues. (It's practically guaranteed considering the variety of databases out there).

Please remove all linear scans from the EF metadata.

P.S.
I've seen databases with 1200 Tables and 16000 columns and 5000 Foreign keys.
The funny thing is, in a typical EF6 query (with cached metadata) 95% of the execution time was spent navigating the metadata (Yup, I've seen methods called hundreds of millions of times during a single query materialization).

[MichalStrehovsky]

@popcatalin81 Thanks for the feedback. The issue at hand is about the metadata used for reflection, not EF metadata.

[divega]

@MichalStrehovsky @DrewScoggins this is very good (and promising) information. Re the different alternative ways to get the performance back, I agree it would be nice if you can get it all without regressing the working set, but if the gains with a cache were much greater, would you see this as something users could choose to enable? Or even plugging in a cache that can evict based on memory pressure?

[MichalStrehovsky]

OK, I have a workaround for you that makes things better. The performance bug is in a code path that is only used when the shared library feature of .NET Native is enabled. At the time the blog post I'm linking to was written, this feature was opt in, but since Update 2 (?) it's opt out (because most people would want it).

If you opt out, you'll avoid the perf bug. It's still not as fast as CoreCLR, but from what I measured on my machine, we're within 25% (we haven't done focused performance work on .NET Native yet - for v1, our focus was _"get it working!"_ - we plan to beat CoreCLR on all perf aspects eventually).

As to the workaround:

1. Right click your app's project in Visual Studio and select Unload project.
2. Right click again and select Edit.
3. Paste this in the first PropertyGroup you see:

<UseDotNetNativeSharedAssemblyFrameworkPackage>false</UseDotNetNativeSharedAssemblyFrameworkPackage>

Save the project, right click and select Reload. Rebuild and check out the perf.

[mvermef]

gonna check this out cause this BUG is a no release for me till its fixed, will absolutely kill tablets trying to view a single query of 260 records.

[MattWhilden]

@mvermef have you tried the workaround listed by @MichalStrehovsky? If that doesn't clear things up for you, there may be another issue we need to get tracked down.

Happy to help, let us know.

[mvermef]

Will find out later this morning when I get up... 😀

[mvermef]

YES!!!!! Instantaneous like in debug build no toolchain, 1 second for 260 records compared to 25seconds... magnitudes faster.

[MattWhilden]

Excellent. Do let us know if you see anything else out of the ordinary.

[abdu292]

I am not sure how it works for @mvermef . It doesn't work for me and the app crashes in release mode. Unfortunately with the latest insider build my Lumia 535 has issues in dumping the crash report (I am unable to set the crash report count to >0 and because of this I have no other way to find out what is the root cause of this crash).
I apologize for the delay. I worked hard on two different UWP apps for several months but had to put on hold because of different issues (most of them are related to Native Toolchain). I invested a lot of time and effort and feeling pain in mind. However I still love Windows and will continue working. For now I just started with Xamarin. I am surprised that it looks almost matured (because it was a paid one before MS acquisition?) and I was able to create almost an app (mainly for Android, and then iOS + Windows) within a few weeks without much issues.

Why is that we have everything slow in the Windows world? See this request was created almost 4 months ago but with a very slow move so far. Even we have a great tool set (I confirm that Windows Dev tools are the best exists today) why the support and feature developments are too slow?

Alright. Please let me know if you have any workaround to get the dump report in release mode or I will wait till next insider build and will send across the dump report as to what was the issue.

I appreciate your support.

[MattWhilden]

@abdu292 can you send details (build numbers etc) to me at [email protected]? Happy to help chase down the crashing issues with you.

[abdu292]

Thank you! I sent across. Please let me know if you need further info.

[abdu292]

Just to clarify, what I meant is if I use the solution given by @MichalStrehovsky my app crashes in release mode, but works if I remove that code from projcs file. I am unable to debug the issue that causes this crash, due to not being able to get the crash dump after the latest insider build on my Windows Phone.
(See attached. After the latest insider build the "Error Reporting" count is always zero and you cannot change it.)

[MattWhilden]

Sure. I'll send that build number to some folks to see if there's something broken with crash collection for that build. In the mean time, if you deploy your app via Visual Studio, my expectation is that the debugger should help us make progress.

[abdu292]

Sure. Here is the exception when we enable the code suggested by @MichalStrehovsky

@MattWhilden Thanks for giving the tip (in your mail) to break at the exception in release mode via exception settings. I thought this is used only to break within a try catch block.

Let me know if I can get further info from this release debug session. Thank you!

[aflx]

@abdu292 I had this problem too (access violation on db migrate). I disabled "Optimzie code" in project build settings and the error was gone...

Maybe not the best option, but for me the only one :(

[aflx]

Damn... Without code optimization, WACK fails with "API CoCreateInstance in api-ms-win-core-com-l1-1-0.dll is not supported..."

Don't know, how to fix this... :(

[aflx]

Ok, I guess I have a solution.

Keep "Optimize code" enabled.
Add following lines to Default.rd.xml (in Application section):

<Type Name="System.Nullable{T}" DoNotInline="true" DoNotOptimize="true"/>
<Type Name="System.Collections.Generic.List{T}" Dynamic="Required All" />
<Type Name="System.Collections.Generic.IEnumerator{T}" Dynamic="Required All"/>

Add this line to the first PropertyGroup in your .csproj project file (like written in a previous comment):

<UseDotNetNativeSharedAssemblyFrameworkPackage>false</UseDotNetNativeSharedAssemblyFrameworkPackage>

(I had to remove my app from the device in order to get it up and running.)

[abdu292]

Hey @aflx Thank you for taking time to respond to this. Yes, it works with the solution you provided and with the configuration what @MichalStrehovsky gave, now the it takes around 6 seconds to load 150 records (it was around 11 seconds before). Though it is a good news that we make some progress, the bad news for me is that I still cannot productionize my app. I am expecting to have this loaded within half a second (like in debug mode).
Hope to see a resolution sooner on this. Please share if you find something more. Thanks again!

[abdu292]

@aflx Wondering if you see the performance that you expect. Do you see it is faster as it is in debug mode and ready for production?

[aflx]

@abdu292 Hm. It seems to be as fast as in debug. But I didn't have numbers yet (I will test it later)...
At least the performance is good enough for me to have a private beta online :)

[abdu292]

@aflx Good to know. Thanks for the response!

[abdu292]

@MattWhilden @divega Team - Wondering if we have any update on this. At least a hint of direction that we are headed to, in resolving this issue? As per my understanding there is not even a work around for this issue.

It is very tough to move forward with our UWP development without you helping us. As we all know working with data is very common. If resolution for this issue gets delayed that can make our development extremely painful. Hope to see a response at your earliest convenience.

[abdu292]

@MattWhilden @divega @MichalStrehovsky A response would be helpful. Thanks!

[janabimustafa]

This really is a breaking issue. I am experiencing slow performance from EF+SQLite when deploying to the phone with the release profile. It takes upwards of 30 seconds to execute a DbSet.ToList opertation on the phone compared to around 3 on the desktop. I've tried every suggestion in this thread and it's still only marginally better.

[mstahl77]

I have had lot of problems with EF+SQLite and .NET Native also. I had to rewrite many queries to not use Include or joins to make it work with .NET Native. And now when I have simple selects without joins there are still performance problems. Trying to do workarounds by caching data in memory now.

When can we expect any performance improvements?

[MichalStrehovsky]

The shipping schedule of .NET Native compiler and tools is locked to the shipping schedule of Visual Studio UWP SDK. We understand the frustration this causes - it's not a good place to be in for us, or our users. Visual Studio is a big project and it takes time to get fixes through.

We are working on solving both problems - to bring the bug fixes and performance improvements required for this particular issue, and to put the .NET Native compiler tools in a position where we can roll out newer versions at a faster cadence. GitHub is not the place where we would disclose timelines for unreleased products though.

[abdu292]

Thanks @MichalStrehovsky for the update. At least we can relax knowing it is being looked at. The silence was pretty annoying with no update.

[MichalStrehovsky]

@abdu292 If you would like to, we have a beta version of the .NET Native compiler toolchain ready to try out.

You'll need Visual Studio 2017 RC. By default, VS 2017 RC comes with pretty much the same .NET Native compiler that shipped with VS 2015 Update 3, but your project can opt in to get the beta:

• Right click the project and select Manage NuGet Packages...
• Make sure to check the Include prerelease checkbox
• Set the Package source to All or Microsoft Visual Studio Offline Packages
• You should see an update is available for Microsoft.NETCore.UniversalWindowsPlatform (version 5.3.0-beta). Install that.

After rebuilding your app, you should see the perf improvements. For your SQLitePerf.zip demo, I'm seeing these numbers:

• 20% faster than CoreCLR on first click on Tap to Load
• About 5% slower than CoreCLR on subsequent clicks

[abdu292]

@MichalStrehovsky Hey, thanks for the response. In reality with your workaround that you suggested in the past (see my comments posted on 26 Sep), I get a better performance from 11 seconds to 6 seconds to load 150 records. However this is still too much from an user's stand point. I would like to have a debug like experience (half a second) before I can productionize my app.

Apologies, 20% with this beta version is not so exciting to me.
Thanks and all of the hard work of the team is much appreciated!

[MichalStrehovsky]

Apologies, 20% with this beta version is not so exciting to me.

Sorry I wasn't clear. CoreCLR is the "debug experience". 20% faster than CoreCLR means 20% faster than Debug.

[abdu292]

Oh. Sorry. I should have been more attentive in reading your comment. I misunderstood that it is 20% faster than the release mode.
It is a great news. I'm going to try this out. I don't have VS 2017 on my dev box however I can spin up an Azure VM to test this.

I'll post my findings at my earliest convenience. Thanks a bunch.

[abdu292]

@MichalStrehovsky Okay. So here is my findings on my project. Please note that I have 4 projects in my solution (excluding test projects) Main, Business, Data & Shared and I upgraded all of the four projects to 5.3.0-beta version.

VS 2017 RC
Debug Mode - Loaded 300 records in 6 to 7 seconds
Release Mode - Loaded 300 records in 6 to 7 seconds (Same length)

VS 2015 Update 3
Debug Mode - Loaded 300 records in 4 to 5 seconds
Release Mode - Loaded 300 records (in the past) in 8 seconds

It appears that in the new version even the debug mode takes a little more than what it used to be in the older version. I would expect the new version of release mode to take less then the time of debug mode of older version. That is 2 to 3 seconds for 300 records. Please let me know your thoughts.

Thanks!

[mstahl77]

@MichalStrehovsky I did one loading test with my App also.

VS 2015 Update 3 (and UniversalWindowsPlatform 5.2.2)
Debug Mode - 1.0 s
Release Mode - 3.7-3.9 s

VS 2017 RC (and UniversalWindowsPlatform 5.3.0-beta)
Debug Mode - 1.5 s
Release Mode - 0.9-1.3 s

Looks like it's a huge improvement in VS 2017 RC with Release Mode. Good work! But interesting that it seems to be a bit slower in Debug mode than before.

[VladimirAkopyan]

I've been struggling with this myself, and tested a few workarounds,since this is blocked maybe it would help someone.
I tried materialising the data into tuples was the fastest way to read the data, see I described this on Stackoverflow
And second I found a no-sql db DBreeze is extremely simple to use, and although it's no-sql, the perf (200,000 records per second) is worth the trade-off in some cases. It's written in c# and support UWP

[divega]

Based on @MichalStrehovsky's update and data reported by users we believe this issue is resolved by the 5.3.0 version of .NET Native currently in beta.

Note that a user also reported the performance on Debug being 50% worse in the new version. If this becomes an issue for development of it turns out to affect other kinds of application we will deal with it as a new bug.

[aflx]

@divega Is it also working with VS2015?

[divega]

@aflx I will let @MichalStrehovsky respond if an improvement is planned that will work with VS2015.

[MichalStrehovsky]

@aflx The 5.3.0-beta .NET Native compiler requires VS2017. Consuming the compiler from a NuGet package requires Visual Studio features that are not present in VS2015.

[aflx]

@MichalStrehovsky Thx! Just downgraded back to 2015 because of some trouble/missing extensions ;)

Just for info: would this work with store releases, too? As fa as I understood, everything is compiled in the cloud, right?

[MichalStrehovsky]

would this work with store releases, too?

Yes, this will work for Store scenarios too, eventually. 5.3.0-beta is a preview release though and can't be used to submit apps to the Store. We're working on having something available soon.

[abdu292]

@divega @MichalStrehovsky Sorry for the late response. I was on my vacation.
I am unsure if this issue can be closed. I was expecting a performance improvement of 4 seconds as opposed to 6 to 7 seconds for 300 records (Please see my comments on Nov 26, 11.20 AM IST - 11 days ago). This issue doesn't necessarily mean we are expecting the performance same as debug any more and that is because in this new version, even the debug mode is affected with the performance issue. I believe debug was affected a couple of times. Because if you see my first post (very first post of this issue) I am saying I was able to run 150 records within 2 seconds (less than 4 seconds for 300 records) with Visual Studio 2015, UWP 5.1.0. However unfortunately that's not the case anymore. Currently VS2015 with Update 3 takes 4-5 seconds and VS2017 RC takes 6-7 seconds (see my comments posted 11 days ago).
Hope to see your responses.

[abdu292]

@divega @MichalStrehovsky I want to re-open this due to reason mentioned in my previous post. I don't see an option to do so. Can any one help please?

[MichalStrehovsky]

@abdu292 Please open a new issue. The original issue (.NET Native being several times slower than CoreCLR) has been fixed and the updated compiler will ship with a go-live license soon. This thread is pretty convoluted and it is not clear what baselines the various numbers are referring to. The EF team will need to have a look at it and determine if the root cause is still the runtime (but since the times are now pretty similar between CoreCLR and .NET Native, it may well be an issue in EF instead).

If you would like to pursue the CoreCLR ("Debug build configuration") regression, please open a separate issue for that too - it's a different set of people who would act on it. I can't speak for the CoreCLR team, but since CoreCLR is not a shipping scenario for UWP apps, the they may only act on it if:

1. The performance is so bad that it makes the Debug builds hard to use (doesn't seem to be case here)
2. The repro case is an ASP.NET scenario (where CoreCLR is the shipping runtime and they take perf very seriously)

[abdu292]

@MichalStrehovsky That makes sense to me. Thanks for the clarification.

[saurabha5]

@abdu292 , @MichalStrehovsky can you please link the new bug here so that we know the actual status. I still see lot of performance lag with .Net native compilation.

[abdu292]

@saurabha5 This issue is not actually on the performance of the compilation, but on the querying of numerous records in release mode. I tested this (I think a week ago), with the latest UWP version, and it looks like it works and no more performance issues. I am going to publish my app now (after holding for a long time)
The .Native toolchain compilation still takes a while however much better than how it was before.