What is the difference in speed between the DLR languages and C# in Silverlight 2?

Question

For Silverlight 2, it looks like programming choices are:

• C#
• VB
• DLR scripting languages
  • IronRuby
  • IronPython
  • A sadly neglected (if not cancelled) Managed jScript

Is this a case where the native languages (C# and VB) are faster than the DLR languages by an order of magnitude or so?

Any hope of "living" in IronPython when I do Silverlight client programming, or should I expect to drop into C# for processor-intensive work?

My survey of languages comes from this set of examples for C# and VB and this page discussing the DLR .

Answer 1

Unfortunately there is no hard and fast answer to this question. Performance of even the same language varies greatly based on a number of parameters.

Yes, in general VB.Net and C# will be faster than DLR based languages. Static languages do more work at compile time such as method binding. This type of work must be done at runtime for DLR based languages and hence they have a bit more cost at runtime.

However, lots of work goes into optimizing the DLR and DLR based languages. Much of this work is mitigated by various caches and so forth. In many types of applications, the performance difference will be negligable.

I would not rule out a DLR based language based solely on performance unless a profiler told me it was actually a problem.

Answer 2

Typically optimizing an algorithm will have a much greater effect than rewriting in a static language.

You might be interested in Show #429 of .NET Rocks, an interview with Michael Foord. Here's a relevant excerpt from the transcript :

Dynamic languages are a lot easier to test, they 're really suited for the Test Driven Development approach that the developers were taking at that time. But I assumed that for performance reasons, they would have to rewrite in C# at some point, and then three and a bit years later we got 40,000 lines of IronPython code, we've got about 140.000 lines in a test code, we've got some type of about 300 lines of C# and every time they come to look at the performance, every time they come and said locate an operation that's not working fast enough, we've been able to get the speed we need by improving our algorithms, by improving our Python code and not having to drop into C#, and the reasons programs run slow is usually not the fault of the language, it's the fault of the programmer, the developer.

Answer 3

Also you could use Boo. Here is sample Silverlight Tetris with boo