+ 2 - 2 | § ¶Which language?
All of them, of course!It is not up to us, as platform developers, to select the language that application developers must use to develop their applications. This is not a topic for gnome-list, this is a topic for business-application-list. We have to provide freedom of choice, application developers will select the language that best fits their needs.
Freedom of language choice is something that any modern desktop solution must offer. For example, I might want to write shell scripts using Perl, desktop applications in C#, Evolution plugins using Visual Basic, OpenOffice macros using JavaScript or MySQL stored procedures using Smalltalk. And maybe my neighbor wants to use JavaScript for shell scripts, Delphi for desktop applications, Visual Basic for Evolution plugins, VBScript for OpenOffice macros and Cobol for MySQL stored procedures. That's freedom of choice.
On the other hand, freedom of language choice is useless if library reuse between languages is not possible. If a company or open source project writes for example, an encryption library, it must be reusable from all available languages. I want to be able to use it to encrypt files from my JavaScript shell script, and to encrypt passwords in my C# MySQL stored procedure. That's real code reuse.
Freedom+reuse (freeuse?) are key concepts for the success of the Gnome desktop in the future, because it makes applications much easier to develop. Companies don't have to learn completely new languages and technologies to start developing for Gnome and Linux, and they can leverage their foundation libraries. All development efforts can complement each other, all achievements in one project can be rapidly leveraged in all projects, even if they use different languages, everything evolves in the same direction.
Finally, there is a set of features and behaviors that should be common to all languages, specially regarding security and stability. Whichever is the language of choice, it must be possible to control and limit the access to system resources. Only having this guarantee it will be possible to share libraries, not only between applications running in a system, but also between applications across the net in a safe way.
And all this is what .NET and Mono was designed for. It offers freedom of language choice, library reuse between languages and fine grained code access security control in a common platform.
We can't say the same about Java.
+ 1 - 2 | § ¶Automatic generation of XmlSerializers
The XmlSerializer can now generate compiled readers and writers on the fly to improve performance, just like MS.NET does.First of all, some background information. When you create a serializer like this:
the runtime creates a map for the class Foo, which contains a list of all serializable members and information about the corresponding xml elements or attributes. In fact, it is a tree of maps, since all classes referenced by Foo (or referenced using the XmlInclude attribute) will have also its own map, linked to the Foo map.
When an instance of Foo is serialized, such as in:
the serializer creates a writer for the Foo type. A writer is an object that gets from the map the members to serialize, gets the values from the object using reflection, and writes the corresponding xml elements. Something similar happens when deserializing an object. The serializer creates a reader, which uses the map as a guide to reconstruct the object.
Sumarizing: the map is created once, and interpreted many times by readers and writers.
However, we can do it better. Mono can now generate readers and writers classes specific for a map, which will use direct field and property access to get and set object values, instead of using reflection, thus making all serialization operations more eficient.
However, this does not come for free. The generation of the readers/writers is slow: Mono has to generate the C# classes and compile them, and then it has to dynamically load the generated assembly. In some scenarios, it is not worth it. For example, when an application has to load a complex configuration file, but it only does it once at the beginning. It is worthless to generate, compile and load an assembly just for one deserialization operation.
For this reason, Mono delays the generation of the reader/writer until a decent number of serialization/deserialization operations are performed. This threshold can be specified using the MONO_XMLSERIALIZER_THS environment variable. For example, if you set the threshold to 50, the XmlSerializer will use the interpreted writer for the first 49 Serialize calls. At the 50th serialization, it will start the generation of the writer, but this is done by a background thread, so the interpreted writer will be still used until the generated writer is ready.
So, you get two benefits over MS.NET: no need to generate the serializer if it is not worth it, and no need to stop the application to generate the serializer.
If you set MONO_XMLSERIALIZER_THS=0 (zero), Mono will follow the MS.NET behavior: it will generate all serializers at the first call, and won't use background generation.
You can also set MONO_XMLSERIALIZER_THS=no to fully disable code generation. This is the current default, until code generation is fully tested.
Another variable you can set is MONO_XMLSERIALIZER_DEBUG=yes. This will tell you when a serializer is generated and the time it took to generate it, as well as the file name with the source code (you'll need to manually delete it). Beware that those variable are mainly for debugging pourposes, I'll disable them when everything is stable.
Does all this really give better performance? Yes, but not as much as one would expect. Raw performance is increased by roughly 50%. However, this is difficult to measure since most of the time is spent in XmlTextReader and XmlTextWriter.
In any case, this is a good number for application that make an intensive use of the serializer (for example, web service servers).
And another conclusion is that the performance of the interpreted reader/writer is not bad at all
