I've heard conflicting information about this subject but, does Runtime support .NET Core? Or, will it?

619
11
03-08-2019 10:34 AM
AlexWalton
New Contributor II

This may be a dumb question, but I am still confused about it.

0 Kudos
11 Replies
dotMorten_esri
Esri Frequent Contributor

At the devsummit we announced that we will be adding support for .NET Core 3.0 to the WPF SDK. Note though that this will be for Windows only, and will not support running it on other platforms .NET Core also runs on.

Timeline depends on when .NET Core 3.0 will finalize, which is currently is scheduled to be "second half of 2019" (see https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-3/ )

We'll need a little bit of time after that release to finalize testing and ensure we'll run great on .NET Core 3.0, so we'll support it in the release after that provided we have enough time for doing the testing (otherwise it'll be in a release following that).

0 Kudos
dotMorten_esri
Esri Frequent Contributor

Just a follow-up to this: The just-released v100.6 has support for .NET Core 3.0 (as a preview). It will however only run on Windows, and will require the .NET Core 3.0 Desktop packages.

We hope to fully support it by Update 7 on top of .NET Core 3.1, but would love feedback now of anything that might not work as you intended.

0 Kudos
BjørnarSundsbø1
Occasional Contributor II

Hi,

I quickly whipped up a sample project for .NET Core 3.0 final to look for performance improvements, and in particular in regards to HTTP/2. However, looking at my IIS server logs, I can see requests made from Chrome are logged with HTTP/2.0, but from the sample application they are logged as 1.1.

It appears that if I handle the ArcGISHttpClientHandler.HttpRequestBegin Event  and assign e.Version = new Version(2,0), the requests is actually performed using HTTP/2. Shouldn't the Runtime use HTTP/2 by default without having to opt-in in this way, or is there something that I'm missing?

Looking at a performance, I notice an odd artifact when zooming in and out on the same spot (one delta of the wheel), while there are no requests being made to the server, there is a visual appearance of the tiles being loaded from server rather than quickly/instantly retrieved from the cache, which I find odd. I already have an intermittent dialog with Michael Branscomb on the performance topic, so I was wondering if this should be part of the direct dialog, or in the forums.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

We are still evaluating whether to default to HTTP/2 or not. At this point we've decided to use the default version of .NET core and not explicitly set it. See https://github.com/dotnet/corefx/blob/release/3.0/src/System.Net.Http/src/System/Net/Http/HttpUtilit...  

As mentioned above our .NET Core support isn't fully finalized yet.

Wrt tile performance I'm not entirely following: Are you saying the behavior is different from .NET Framework? We shouldn't be making requests to the server again for the same tiles if the server said that the tiles can be cached.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

FYI I've filed a request to update the incorrect .NET Core doc: 
https://github.com/dotnet/dotnet-api-docs/issues/3319 

From my understanding the http/2 implementation in .NET Core isn't fully complete, which is why it isn't default. Once .NET Core considers it feature complete, you should automatically see v2 requests happening. I think that's a better approach than we forcing a version number on the requests (and until then you can use the workaround you found)

0 Kudos
BjørnarSundsbø1
Occasional Contributor II

Interesting. We are not quite ready to update to .NET Core yet, so we still have some time to work on it, and for MS to do the same. So in the future, the runtime will hopefully use the most suited protocol.

0 Kudos
BjørnarSundsbø1
Occasional Contributor II

There are a few situations I've been looking into in regards to performance.

Comparing .NET Core vs .NET Framework

I've created two identical sample applications, except for one is .NET Framework 4.7.2, and the other is .NET Core. They both use HTTP/1.1 and the same initial extent. 

Manual testing:

It feels like tiles take longer to complete drawing (DrawStatus.Complete) in the .NET Core application, compared to the one in .NET Framework, when zooming in and out in the same place.

Automated testing:

Both applications start working at the same time, and perform zoom in/out in tandem. Using this approach, the trend seems to be that the .NET Core usually takes longer, but I don't have definite proof, as they sometimes seem to change who takes the longest, based on stopwatch before performing SetViewpointScaleAsync, and DrawStatus.Complete. I don't know if the ServicePointManager.DefaultConnectionLimit Property (System.Net) | Microsoft Docs is affected across processes, and could have some sort of impact.

Tiles from cache

The real cause I noticed this, is the behavior in the attached animated GIF (hopefully it is displayed here). This is a rather large screen, which makes it more obvious. The tiles are loaded from cache, but the delay in drawing them is quite noticeable. 

0 Kudos
BjørnarSundsbø1
Occasional Contributor II

It appears animated GIFs are turned into png, so the behavior is rather difficult to demonstrate with that format I have a 35" wide screen, and creating a map with Basemap.CreateLightGrayCanvas(), maximize the window, go to i.e scale 50.000, and zoom in and out between 1:25.000 and 1:50.000. in my sample, it takes between 2-4 seconds between start of SetViewpointCenterAsync and DrawStatus.Complete.

On a standard 24" monitor, this duration is between 700 and 1500ms. Event handler for Esri.ArcGISRuntime.Http.ArcGISHttpClientHandler.HttpRequestBegin is not hit, so tiles are retrieved from cache.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

I've done several perf testing runs comparing .NET Core and .NET Framework. I see the interop performance about double in speed (similar to what we were already seeing with UWP's .NET Native runtime), but in grand scheme of things those are very small overheads, so in practice it didn't make much difference in real-world scenarios (as most of the work is actually done in native code, and it is the exact same native DLL being used by both). There might be a few places here and there where you'd see some of .NET Core's new features have an effect, but don't expect to see a huge benefit yet. Also make sure you compare Release build performance.

In addition we're not (yet) taking full advantage of things like Span<T> etc (and neither is the WPF framework), so we potentially have room for improvement, but as mentioned earlier the bottleneck is actually rarely the .NET side of things, so it would really only have limited impact. We're currently having a high priority on performance on the .NET side of things, and diving into various hot-paths and making targeted optimizations where we can, and will use new language features just for the .NET Core build when that makes sense. You should hopefully see some improvements here and there in v100.7, but this is work that we will continue over many releases.

It's hard to rely on DrawComplete and the async set-viewpoint methods for performance testing, as they are timer-based, so even on a slow machine, a zoom is going to take roughly the same amount of seconds (but it might skip some frames and be more "choppy" to keep up), and DrawComplete is unfortunately slightly unreliable right now and might be several frames off. Also your resolution for these tests would be limited to (at-best) the framerate during the operation. Also make sure you perform these tests without the debugger attached.

DefaultConnectionLimit: we default to 6, but will respect it if you set a _higher_ default value (as long as it's not int.MaxValue). Anything beyond 10 doesn't seem to have much effect, but once you do go above 6, you'll start seeing quite a lot of CPU usage, so I really don't recommend changing it (in .NET Framework is 2 and we used to use that. By changing it to 6, we saw about 2.5x improvement on tile loading. Going to 10 was about 3.5x faster, but CPU usage started to spike. Higher than that had little-to-no effect. We settled on 6 as it appears to be the defacto standard and in our testing also showed a good trade-off between performance and CPU usage).

If you have a sample app you can share that shows the differences you experience between .NET Core and .NET Framework, I'd love to take a look. I'd definitely not expect things to run slower (albeit I wouldn't expect it to be much faster either).

0 Kudos