Comment by MrRadar
7 years ago
I have a similar experience. I'm a developer on a product that has both C and C# components. The C component runs on both Windows and Linux and is by far the larger of the two while the C# GUI component is Windows-only.
Our main workstations are Windows but we also have a shared Linux development VM on our group's VM host. The VM host is not very powerful, it's a hand-me-down machine from another group that's around 7 years old at this point, with a low-clocked Bulldozer-based AMD Opteron CPU and spinning rust storage. In comparison my workstation has a 4th-gen Core i7 processor and a SATA SSD.
Despite the fact that my workstation should be around 2-3x as fast per thread and have massively better disk I/O the VM host still builds our C code in less than half the time. If I didn't have to maintain the C# code and use MS Office I'd switch to Linux as my main workstation OS in a heartbeat. (Note that the compilation process on neither platform uses parallel compilation so it's not that our VM is farming the compile out to more cores.)
In a similar situation - I've had reasonable success in Linux developing a .net framework c# app in VS Code with Mono from the Ubuntu PPA. Almost everything works but for the odd project calling native Windows DLLs, so I keep windows around for manipulating VS projects and compiling these oddities. Most dev can happen in Linux though.
In my case we use a closed-source commercial UI library very extensively whose vendor has previously stated they have no interest in supporting Linux or WINE so doing C# dev on Linux is totally out of the question for me, unfortunately. The company I work for has a long-term strategic initiative to transition to an entirely web-based UI so eventually we may be able to remove the C# code but that's still years off for my group.
(In retrospect tying ourselves to a closed-source library like that was a mistake; if I could go back in time and put us on a different path (using the technologies available at the time) I would have gone with C++ and Qt instead which would have allowed for cross-platform development and deployment. Not to mention that because Qt is open-source (even if we would have had to buy a proprietary license for it at the time) we could fix any bugs we encountered ourselves, unlike our current UI library where we just need to come up with work-arounds until the vendor can get around to fixing them. But these decisions were made before I was hired so I just have to live with them.)
I am not a C# dev, so please bear with me.
So you have you core business logic and algorithms written in C and only the front end/GUI uses C#? Can you cleanly separate the two (via MVVC or a variation thereof)?
Does the whole application runs on C# and you have RPCs between the two? What does that mean for performance?
Cheers and thanks for any Insights about your setup.
It's a pretty classic client/server setup (not too different from modern web apps, actually). The C code is the server and the C# code (which is actually a plugin to another application written in C#) is the client. The C server can run independently of the C# clients but isn't very useful (to our customers at least) by itself.
Most of the C# code's responsibility is taking user commands from the plugin's host application and converting them to messages sent to the C server for further processing, which isn't very speed/latency sensitive most of the time since it only has to operate at user-perceivable timescales and on small amounts of data. The remainder of the C# code is some custom UI controls and dialogs.
The network communications (if you squint hard enough) somewhat resembles REST with custom binary protocols instead of HTTP and JSON; if REST were in style when this code was first written (around 10 years ago) it almost certainly would have been used for the network/message layer instead.
Do you take the buffercache into account? If the server has more RAM unused by processes it probably uses it as a cache, which can be 3x quicker than a SSD.
Both machines should have sufficient memory to cache the entire codebase (including all header and library files) in RAM.
Why not flip to linux and run Windows in a VM?