- Thread starter zerodowned
- Start date
OP
I honestly don't know enough to say for sure. But faster loading and using less memory certainly sounds promising.
I have not tried to compile ServUO to native code yet but I have done so in other apps. I seen no performance upgrades except for a few ms faster startup time (Within the margin of error so I disregard). One huge downside was a waaaayyyy longer compilation time. Like WAAAYYY longer.
Another positive for some developers is that since the binary is compiled to native code instead of basically a container containing your c# code for the framework to read your binary will be much harder to decompile and steal. As much as c would be anyway.
Also, if you use F# or are fond of any F# DLL's then you are out of luck, .net native does not support it.
Honestly, I am excited. I am looking forward to seeing how it goes. I believe it is only windows 10 though which kinda sucks. I could be off on that though.
Another positive for some developers is that since the binary is compiled to native code instead of basically a container containing your c# code for the framework to read your binary will be much harder to decompile and steal. As much as c would be anyway.
Also, if you use F# or are fond of any F# DLL's then you are out of luck, .net native does not support it.
Honestly, I am excited. I am looking forward to seeing how it goes. I believe it is only windows 10 though which kinda sucks. I could be off on that though.
OP
good to know.
it was my understanding that it is Win10 specific as well.
So it turns out it is only for windows 10 store applications right now, it was just a happy coincidence that the app I was working on at the time was a store app.
It would be useless for ServUO anyway since we load code dynamically so JIT is required.
It is pretty awesome though. All the .net framework stuff such as the garbage collector actually gets compiled into the native exe, you don't need to end user to have the redistributable installed on their machine or anything, they just run the exe. I figure though you will need to create binaries that target specific architectures though such as x86 and x64 instead of the framework telling the app what to do.
It would be useless for ServUO anyway since we load code dynamically so JIT is required.
It is pretty awesome though. All the .net framework stuff such as the garbage collector actually gets compiled into the native exe, you don't need to end user to have the redistributable installed on their machine or anything, they just run the exe. I figure though you will need to create binaries that target specific architectures though such as x86 and x64 instead of the framework telling the app what to do.
I can also confirm its for the store applications right now. But thats because they target .Net Core Native (https://github.com/dotnet/core). There is a lot of missing functionality, so so its going to be some time before something like ServUO can use it. A lot of things are changed, mainly libraries need to be portable, File IO is different, a lot of things are async/await, meaning ServUO would have to change a lot of method signatures to use Task async/await patterns. The nice thing will be however, .Net native is being created to be cross platform, so one day, ServUO will be able to run natively on Linux. One day, it will be possible, but it will require ServUO to be rewritten from the floor up, so I don't know that it will happen, not sure anyone is really up to that task, but we will see. I see async/await being the biggest problem. I use it every day at work, and have become the resident expert in it. It has a lot of caveats that Microsoft doesn't really explore in most of their samples/blogs/etc. An example of that for those that are interested is something know as "async void" and how the calling thread into a "async void" can hand off it's processing to another thread while the function has not finished, meaning the caller continues on, but the code executing inside the "async void" may not be written with this in mind.
High level example:
Now, lets say you run this code
The console writes "0" because it the calling "Run" function doesn't return a task, so the caller doesn't know its a long running asynchronous function. Therefore, it does not know to wait for the Task Delay. So, the practice that has to be used is Run has to be transformed into an async call.
And now running the following:
Writes "5".
So, what I'm getting at, is that all the functions from the top most call to the bottom, need to implement Task async/await patterns, and thats a huge undertaking. All the File IO functions in .Net Native use async/await, all the Net code, uses async/await, I can go on.. .but I think you guys might get my point
TPL is a bitch because of these issues, and its really only scratching the surface as far as caveats go. The entire .Net framework is fragmented at the moment because of TPL, having to use a mix of TPL + non-TPL causes a lot of issues, and Microsoft needs to catch up as far as writing most of .Net with async/await pattern code, but again, time, it takes time.
I think I may have gone off on a tangent... its late.
High level example:
Code:
private int _value;
public async void Run()
{
_value = 0;
await Task.Delay(1000); // wait 1 second
_value = 5;
}Now, lets say you run this code
Code:
Console.WriteLine(_value);
Run();
Console.WriteLine(_value);The console writes "0" because it the calling "Run" function doesn't return a task, so the caller doesn't know its a long running asynchronous function. Therefore, it does not know to wait for the Task Delay. So, the practice that has to be used is Run has to be transformed into an async call.
Code:
public async Task RunAsync()
{
_value = 0;
await Task.Delay(1000); // wait 1 second
_value = 5;
}And now running the following:
Code:
Console.WriteLine(_value);
await RunAsync();
Console.WriteLine(_value);Writes "5".
So, what I'm getting at, is that all the functions from the top most call to the bottom, need to implement Task async/await patterns, and thats a huge undertaking. All the File IO functions in .Net Native use async/await, all the Net code, uses async/await, I can go on.. .but I think you guys might get my point
TPL is a bitch because of these issues, and its really only scratching the surface as far as caveats go. The entire .Net framework is fragmented at the moment because of TPL, having to use a mix of TPL + non-TPL causes a lot of issues, and Microsoft needs to catch up as far as writing most of .Net with async/await pattern code, but again, time, it takes time. I think I may have gone off on a tangent... its late.
