CLR Inside Out - Building Tuple

re: CLR Inside Out - Building Tuple

energex — Thu, 02 Jul 2009 02:00:53 GMT

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

re: CLR Inside Out - Building Tuple

Melitta Andersen — Fri, 03 Jul 2009 02:02:48 GMT

For your second question, you might want to check out the documentation for StringBuilder, specifically "Performance Considerations" section under the Remarks. The documentation can be found here: http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx

re: CLR Inside Out - Building Tuple

Daniel Earwicker — Fri, 03 Jul 2009 12:53:42 GMT

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. :)

re: CLR Inside Out - Building Tuple

Daniel Earwicker — Fri, 03 Jul 2009 13:12:10 GMT

"The F# team was very concerned about tuple being a very lightweight type, because it uses so many different generic instantiations of the type across its product. If Tuple were to implement a large number of generic interfaces, they felt it would have an impact on their working set and NGen image size."

Did they test that too?

re: CLR Inside Out - Building Tuple

Matt Ellis - MSFT — Mon, 06 Jul 2009 21:08:33 GMT

@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!