CLR Team Blog

I have a simple question.

Everytime a program is fired up, I am aware that there is new application and domain object instanciated.

Question is, is there  new CLR instance or is there one CLR hosting all application, can I force two CLR instances?

What level of depth does the boundary and isolation stop at.

Second question:

In the MSIL there is only one constructor for multuiple string concationations - I dont understand why or how this behavior is different from the other base class objects

For String A = S + G + C...

where they are all strings

Look at the above after fixing the syntax and you will only see on ctor() ????

thanks

Brilliant, would love to read more things like that about how things get into the BCL, CLR or languages (similar to Stroustrup's D&EC++).

The standout message of that article has to be "we changed the design so that all tuples are reference types, although we asked the F# team to do some performance investigation to see if it experienced a speedup when using a value type for some sizes of tuples. It had a good way to test this, since its compiler, written in F#, was a good example of a large program that used tuples in a variety of scenarios. In the end, the F# team found that it did not get a performance improvement when some tuples were value types instead of reference types. This made us feel better about our decision to use reference types for tuple."

When I first started using C# I made the mistake of assuming that structs should be used wherever possible for lightweight objects to reduce the pressure on the GC. But it was pure guesswork (based on experience with the C++ heap) and not at all confirmed out by experiment. I've found the CLR GC seems to allocate/deallocate with performance close to the value-type stack, at least when objects are short-lived.

It's good to know that even the F# team leapt to the same assumption. :)

@Daniel Earwicker

I don't believe that F# did any tests around NGEN image size.  If they did, I didn't see the results.

However, we did talk with some folks on the JIT/NGEN team and they agreed that this was an issue we'd need to be careful around (not that it's something we couldn't fix later by making improvements in NGEN).  

Ultimately, we decided that there weren't any generic interfaces we really really wanted to add to the type right away which let us not worry about doing these sorts of investigations.

Glad you liked the article, thanks for the great feedback!