How much power is too much?
In the second section of the Channel 9 tour videos, Rico Mariani talks about performance and I once again butcher his last name (I once made the same mistake at a BillG review, sorry man <sigh>; it's pronounced "Mary-annie", got it now <g>).
One thing we've seen a lot is that it is really easy to take one or two lines of managed code and really blow your working set and startup time. It's a double edged sword. On the one hand, you get a really easy to use class library, on the other you don't feel the pain that would otherwise make you think twice about using an expensive feature.
Two concrete examples include the XML serializer and compiled Regex expressions. I've seen requests for Assembly.Unload() that really are due to having these extra dynamically generated assemblies around. This performance report on the internal Headtrax application explains how that application invoked the C# compiler 16 times at startup! (this is discussed in the interview section with Scoble coming up in a new segment). If your application is slow to start, see if you are making this very easy mistake.
We've kicked around a bunch of ideas on this in the past. Obviously our first goal is that you always get the fastest solution by default (you should precompile your XML serializer code for example). We've toyed with giving you a "red/yellow/green" gradient in the docs or Intellisense that would hint at where you are using an expensive feature. Profilers are also useful for you to figure this kind of stuff out; but do require work and planning.
So my question for you: how much power is too much? Should we be making the library much more "in your face" or harder to use for things that are really going to cost you? What are your favorite "feature rich" API's that might be causing this unexpected/unwanted overhead?
Comments
- Anonymous
November 18, 2004
The comment has been removed - Anonymous
November 18, 2004
The comment has been removed - Anonymous
November 18, 2004
It was the XML serializer that caused the 16x compiler invocation. I would argue it is not the developers fault that they want to use any easy way to serialize data to a human readable file. The problem is that the XML Serailizer was released at all with this intrinsic performance problem.
All the compilation could be done at design/compile time. At that point the structure of the serialized objects is known. So perhaps a better design would be:
- an xml serializer that uses a fast form of reflection, and a sub-set of xml, and no compilation or
- an xml serializer that does not use reflection, but generates the IL at design/compile time, rather than run-time.
Either way the full xml spec is overkill for data serialization. - Anonymous
November 19, 2004
>What are your favorite "feature rich" API's that might be causing this
>unexpected/unwanted overhead?
Also on the XMLSerializer front, how about the fact that some constructor overloads generate the serialization assembly and then don't cache it. If you use that constructor form repeatedly, you essentially leak assemblies (since they never get unloaded). Totally undocumented, of course. - Anonymous
November 20, 2004
I agree with David that a developer has to know what he/she is doing in order to do a good job. But unfortunately, there are always some developers who are not as aware of what to watch out for (myself included). I'm working on a team where even my team lead isn't aware of the performance cost of all the boxing/unboxing operations we are making. Unfortunately, my opinion was taken as a challenge to my team lead's technical ability. So I kinda like the idea of giving hints at the IDE level. Note that they are just hints. At least I hope the hints (coming from Microsoft) will prompt the developer to look deeper into the API that is being used.
Profilers and tools like FxCop are great too, but only if the developer uses it. - Anonymous
November 27, 2004
In one of your videos, you kind of remind us the history of the CLR run-time, originating from COM+, and languages like C++, VB. I think your statements are unfair, and filled with the real agenda, which is to absolute vanish any of your public speaks with anything related to Java, the run-time, JIT and SDK.
I find it absolutely odd that the MS Java VM 3.0 was their at that time, doing ABSOLUTELY EXACTLY what the CLR run-time, JIT, interop and base classes are doing these days, and you still want us to think that you wrote these things from scratch.
All when even Helsdberg was working on Visual J# at that time, the IDE for the MS Java VM.
A lot of gibberish IMHO. - Anonymous
November 27, 2004
By the way, I have another question, one that my resonate why so little people have embraced .NET on the client (I believe .NET applications just cannot be generally deployed, but that's another story).
How come only apps developed at Redmond have been successfully able to host the CLR in an unmanaged app and do anything meaningful with it? Examples : ASP.NET, VisualStudio of course, SqlServer Yukon.
So? Do you think that improving the design the of this plumbing and making it really usable from a developer perspective would improve anything, or is it good enough? Statistics don't speak a lot for your camp, yet you might come with words telling how much successful .NET has been so far... - Anonymous
November 28, 2004
Where there is an particularly complicated API I like a two-pronged approach. Provide a simple API that covers the 80% set of use cases. Then provide a more flexible, feature rich, full API that covers all use cases. I don't mind if the full API is a bit more complicated to use (unless it is arbitrarily complicated). It is also reasonable that the simple API sits on top of the full API. One of my favorite examples of this in the BCL is System.Net.Sockets.TcpClient/TcpListener (simple API) versus System.Net.Sockets.Socket (full API). Another example of this is the My classes feature of VB 2005. - Anonymous
June 08, 2009
PingBack from http://hairgrowthproducts.info/story.php?id=1828