As .net native only support windows store app, I don’t think it is quite easy to adopt in your .net winforms or WPF app at the moment.
If you really need performance, maybe you can also consider using the .net core 3.0 framework with the Span type, it is is allocated on the stack rather than on the managed heap. You can use pointer, also.
Actually in my case, the .net app is fast enough, and I never use pointer.
Also, actually measure your app first, because contrary what many “native proponents” might like to lead you to believe, .NET core doesnt really run slower as “native” code, per se, because it does in fact run natively, once it’s JIT-compiled. Some 20 years later, and some nay-sayers still make it out as if .NET is like a BASIC interpreter from the 80s — it’s not, and I’d wager that most average application code will see zero benefit from being converted to native (especially compared to other optimization opportunities that almost every code base will have, within the managed space).
just my .02.
It’s not about performance of the application. It’s about performance of the machine.
If you are using a machine on your own., you have power to spare to JIT the code, but if you are working on a terminal server with 50+ other users, everything that gets memory or CPU down (even if it is only a little bit) will improve the performance of the machine.
The power needed to compile has already been used (once) with native compiling - with JIT, you need the power every time it runs. I know - there is pre-JIT, but I have bad experiences with that.
if you keep quitting and relaunching your app, yes. id assume most “server” solutions where this would eb a constraint would be services that start once, JIT once, and then keep running though?
No I am talking Terminal Server - so 50 users doing their job, starting and closing applications as they see fit.
I see. even then, I’d measure first, because this is still 50 people using the app to do some sort of CPU-intensive processing, one would imagine. So what percentage the actual load would be the JITting? A complex app like Water starts up in a split second. If I use it for even one minute, we’re already talking less than 1% of the CPU load being spent on the JIT vs. 99+% being spent on what the app actually does…
Point is: 1% cpu * 50+ users = 50+% CPU.
All little bits help.
That’s not how percentages work ;).
if (less than) 1% of your app’s CPU issued for JITting and (more than) 99% are used to run it, then running 50 instances, its still only (less than) 1% of the overall resources that’s spent on JITting.
Sure, if you have exhausted all others areas of optimization, once can look at the last 1% (really, more likely to be 0.001%, unless your per-run app usage is super short), but even if you can get a 10x gain on the 0.001% of JITting (and you probably won’t), it won’t handle make a dent.
Sorry to jump in
Is Water developed in Oxygene.NET? Is appears running faster than old versions. What magic did you do? It is pure managed code, right?
Water is and has been since the very first build, fully managed code, all compiled with Elements, and using WPF for all the UI.
The bulk of the IDE code is RemObjects C#, not Oxygene, for historical reasons. It is essentially the same code base as Fire, and, back in the long ago, Fire started out written in Objective-C because I wanted a pet project to work on on my Mac laptop w/o needing Visual Studio in a VM ;). Once it got good enough to self-host, I converted that code base to Elements with Oxidizer, and I chose C# for two reasons (even though I myself prefer Oxygene): For one, (a) RemObjects C# was new at the time, and it needed a good internal dogfooding project and for another more importantly (b) by that time I was very familiar with the exiting Fire code base, and converting from one C-based language to another felt like it would preserve the code I knew more closely than converting it to Oxygene instead.
Two secondary considerations where that (c) code that failed to convert cleanly with Oxidizer was more easily adjusted form Objective-C to C# than to Oxygene, as well and (d) that back then Fire still did not have IDE smarts such as class completion (and Oxygene had no Unified Class syntax yet, that was years out), and writing C# was easier than writing Oxygene because there were no interface/implementation to (manually) keep in sync.
Since then i’ve gotten used to it and started to appreciate (our) C# more, so I’ve stuck with it. So that’s why, some six or seven years later, Fire/Water is still all C# — but it still uses our compiler, both for the Fire, which is of course build for Cocoa, and for Water, which is built against .NET.
Of course Fire/Water use a lot of other code bases; all the compiler, IDE smarts, debugger & co (which are always managed, even in Fire where we load them in via Mono) are written in Oxygene; EBuild is written in Oxgene, as well.
I have, quite literally, done zero deliberate profiling or performance optimizations for Water, at this stage. It’s as fast (or slow) as it is, from the get go. A few things are “hand-optimized” back from the Fire-only days and Water benefits from some of them, for example I’ve optimized the heck out of the code editor’s drawing routines to make the syntax highlighting and rendering really fast and cached).
Thank you marc for the detailed and very interesting historical perspective.
The RemObjects website is developed in ASP.NET/Oxygene, right?
Correct, yes. the website is ASP.NET, 95% Oxygene, some Swift (the bug tracking section and Renewals sections, because they share code form internal tools that I happened to write when Swift needed dogfooding ;). It uses the ASP.NET “website” model, where loose .pas and .aspx files are uploaded to IIS and are compiled on server on he fly (In fact, the Elements compiler itself lives in the ./Bin folder of the site, so if I need to update that, I can just upload a new copy (and have separate versions for Staging vs/ Live) — this model makes it super easy to stage and selectively publish changes. Essentially, I have two copies of the site on our server, one live, one staging. When I work on the site I upload to the staging site (directly from Fire, via a a special “website” mode that isn’t quite ready for everyone to use yet; basically I just press ⌘S and all my changed files get published), so I can test my changes. I then use a simple diffing tool, Araxis Merge on the server to compare live vs. staging and decide what changes (whole or even partial files) I want to move to the live site, when done. Very flexible.
The site also uses Data Abstract for .NET for all data access, and applies local caching for things that don’t change frequently (such as most opt the prose blocks).
While we’re discussing how all works, it’s hosted on an Amazon EC2 instance, and the database (Microsoft SQL Server) in in RDS; that way, we can leverage proper failover support — if the EC2 server hardware dies, which they do every few years, I can just boot up a new one ;). Also makes it easy to scale out ion we ever have to (but for now, one (low-end) instance handles it all fine…
No separate server hardware for the middle tier (would just be a needless extra cost), it just runs on the same EC2. Thats same DA server also serves the data for our internal goals (say, for sending renewal notices, or managing users/licenses).
I converted the c# Zlib library from .net to island… wasn’t that hard given c# is not my first language.
Got it going only .net and then copied it to an island project so I had both up at once.
Issues were a couple of .net functions not available in .net, bitconverter and array.clear (now add to to the rtl2). Also streams not 100% .net compatible. Now I’ve done one conversion I’ll feel confident that the next one would be easier
Now it is running I’d love to convert to oxygene but as it stands oxidizer mangles the code a fair bit. I’m hoping this will get sorted and I can use the Zlib library as a dog fooder and example of how to port .net to island to oxygene.
I really enjoyed the project and was stoked when I finally got it going 
I totally agree that. I would rather spend more time on improvement the algorithm, and sometimes I may use parallel.foreach, that’t enough for me to get the speed I want. I don’t want to bother converted to native 
Bug reports appreciated. That said, Oxidizer will never do a perfect translation.
You should look at doing a Shared Project with the code, so you can compile one code base to both targets (or a multi-target project, but IDE support for those isn’t fully baked yet)