Theory vs. Practice

Diagnosis is not the end, but the beginning of practice. Martin H. Fischer

› What makes a company "perform"?

Not all startups land gracefully when the hype must leave room for results. And we have more modest shops that do common things, just much better.

So imagine my surprise when I tested Mono – the C# implementation available on Linux – to add support for C# G-WAN scripts.

---

Hard facts

To start with, the Mono runtime, a C library, adds 5 MiB to the server. Compare that to the 12 MiB of the JVM, or to the hundreds of megabytes of the IIS .NET runtime.

The Mono documentation was as frustrating as the one of its elders. But I managed to make the damn thing work as expected (I am still unsure with the JVM, despite months spent at exploring gazillions of documentation pages, as many critical areas are left unaddressed). So, despite the flows of the Mono documentation, something must be better – and (tip:) that's most likely its (much) smaller size.

After the first-glance views, let's have a look at the really great things:

• I got a reply from a Mono developer. At first this reply did not really help but I never got any reply from the authors of Java or .NET. We will see below that this alone has made quite a difference.
• I found a way to directly address a Mono string from C – and it allowed me to save time during the utf16 to utf8 data copies, making Mono much closer to C than Java as a viable G-WAN script engine!
• I got really valuable help from the Mono developer (thank you again Lupus) when I asked a more Mono-specific question. My C# code was corrected and returned to me the day after – during the week-end.

This kind of instant informal collaboration is priceless. OK, I demonstrated my commitment first (making Mono work) so Lupus knew that I was not going to waste his time, but even after that he was not obliged to help me.

Given my previous publications about C#, he could have assumed (a bit too fast) that I was against C#, and therefore reject the idea of giving any portion of his time to someone seen as "an enemy". I am against bad actions (like bad work), not against people (most do their best with what they have). So, as we will see below, I am not the enemy of anyone doing his best.

Back to the subject: what makes a company "perform"?

• The same reason that makes it reply to total strangers.
• The same reason that makes it write better products.
• The same reason that makes it grow its business.

  Necessity.

When incumbants have forgotten where they come from, when their future is guaranted by finance (revenues not obtained from product sales but rather from capital invested in financial markets), when they have lost all the incentives because appearances can be purchased, then all necessity is gone.

And it is gone for good.

To those shareholders who bet on he future of their investments, I have this to say: see the "too big to fail" feat as the sign of beeing doomed to fail because instead of questioning itself, for the sake of convenience this dead-fat will go as far as to bring the system down rather than to accept change.

As there are so many more ways to destroy value than to build value, incumbants are fighting all change – dooming themselves.

Without the much needed penalty of failure (the only way to learn and make progress), incumbants get more and more inadequate. And artificially maintaining them alive with liquidities widthdrawn from more sane activities will just break the balance that makes it possible for investors to invest in the first place:

The ultimate result of shielding men from the effects of folly is to fill the world with fools. Herbert Spencer

Right, OK, But Is Small Always Beautiful?

No but more than often: Mono's IDE called mono-develop is a brilliant illustration of that fact: as compared, gEdit (established for a longer time and written in C/C++) lacks both in usability and scalability with large files – making it useless in many cases.

On the less bright side: while the Mono C# script engine – for the particular use tested here – was rather good, the same cannot be said of the Mono-XSP server which is lagging as compared to Java servers (like GlassFish, Tomcat or Resin, previously tested at 160k requests/sec, a number close to the tenors like Nginx or Lighty):

Mono-XPS is 20x slower and it does not sustain concurrency growth.

Its RAM and CPU usage is also a concern (strangely, the user-mode and the kernel-mode follow the same curve, that's rather unique).

IIS did not do that well to serve C#, but under Linux there was an opportunity to do better – and Novell and Xamarin later did a good job with Mono.

Started 8 years ago, Mono is a promising but unfinished server platform (Mono will work fine as a client).

This is what makes G-WAN's C# support so interesting: it's clearly filling a gap: how to make C# fly as a server-side scripting language.

High-performance and low CPU / RAM resource usage, this G-WAN signature proves to be true again for yet another script engine.

And G-WAN outdoes all other solutions for both static and dynamic contents.

See the charts below.

The tests published for G-WAN show a few important things:

• Not all  application servers  are equal.
• Not all  programming languages  are equal.
• Not all  corporate environments  are equal.

And in all those cases, what makes the difference is the implementation, the execution, the level of attention, of care of the people involved in the exercise. What makes the difference is the nature of the incentive: necessity.