Performance of Nine Languages Compared

OSNews has an article comparing the performace of different languages to each other.  C# kills VB.NET in the IO category.  Why?   Take a look at the VB code vs C#.

C#

StreamWriter streamWriter = new StreamWriter(fileName);
while (i++ < ioMax)
{
     streamWriter.WriteLine(textLine);
}
streamWriter.Close();

VB.NET

FileOpen(1, fileName, Microsoft.VisualBasic.OpenMode.Output)
Do While (i < ioMax)
     PrintLine(1, myString)
     i += 1
Loop
FileClose(1)

13 Comments

  • This is just biased code. The C# code will run (changed to VB.Net syntax) just fine from VB.Net. VB.Net has access to teh same framework objects.



    Sounds like the benchmark is useless - its comparing vb6 code running under the .Net framework to framework code.

  • Couldn't you pretty much write the same thing in VB.NET (except for the increment operator)



    &lt;pre&gt;

    Dim streamWriter As New StreamWriter(fileName)

    Do While (i &lt; ioMax)

    streamWriter.WriteLine(textLine)

    i = i + 1

    Loop

    streamWriter.Close()

    &lt;/pre&gt;



    Now isn't that the same thing, should be the same number of calls as the C# version? The i++ turns into a i = i + 1 just like the VB.NET line. Of course, you are going to easily type 30% more in VB.NET than C# but that's another debate.

  • I was quite suprised to see how well java 1.4 did ( apart from the trig ), better than c# on a lot of things :|

  • I agree with the first comment.



    OSNews needs to compare apples to apples, not apples to oranges. Just because you can do it that way in VB.NET doesn't mean you should - and shame on Microsoft for giving people who don't know any better the ability to do it.

  • Argh.



    Argh, argh, argh.



    Like I'm going to choose C, Java, or C# because of a few ticks difference.



    What I *really* want to know is why the lights dim and the ground rumbles whenever I try to open up Java GUI apps (not the little toy apps, but think more along the lines of the WebSphere admin piece, or any IDE written in Java).

  • Let me suggest to learn VB.NET better, before wasting time on this kind of benchmarks

  • So if you guys can provide better written code then why don't you do so? I'm sure that whoever did the benchmarks wasn't an expert in every language. Write your optimized VB (or whatever) version and send it to them.

  • Because do you honestly think the person who wrote it really wants the optomized VB? Was it so hard for them to find someone who could provide it?

  • Interresting thing about this is that managed code doesn't lead to an expensive overhead as compared to native C language compiled with GCC. As the author of the benchmark concludes, the few - hypothetical - percent of performance advantage for native languages are not enough to justify to stay away from managed code and not to take advantage of all the mechanisms provided by the CLR.

  • (i can't believe I'm about to defend an author who publishes such a shocking piece of VB...)



    The author actually highlights an important point here. VB programmers who have upgraded to VB.net are quite likely to write code just as bad as that shown. C# programmers will have tohave a solid grasp of the framework and will almost definitely write code similar to that shown. So in practice, the comparison might actually be a fair one.



    Still, in the time it took theVB programmer to write the code get it working, deliver it, deal with the client and fix ten more problems, the C# programmer would've just walked around the office ten times, showing off about how clever he is.

  • Leon - Exactly! And that's why I made the comment that Microsoft should shoulder some of the blame for deciding to include this VB compatibility library that makes such things possible. On one hand, I can't fault MS at all for their good intentions on making the upgrade path from VB6 to VB.NET as smooth as possible, but on the other hand if we don't provide the &quot;incentive&quot; for them to learn how to do it a better way (some might say &quot;the .NET way&quot;), then we're going to be faced with cleaning up this type of code for years to come.

  • &quot;The author actually highlights an important point here. VB programmers who have upgraded to VB.net are quite likely to write code just as bad as that shown.&quot;



    The problem: It's supposed to be a benchmark of languages/platforms - *not* a benchmark of developers.



    That said, I don't care what language you code in - 90% of the code that I've encountered in my contracts has been utter, dismal puke. It could, if we really wanted to screw up the benchmark this much (more so than it already is), be argued that any developer approaching any language/platform has about a 9/10 chance of totally botching the job regardless of knowledge.



    I don't think there's any justifiable reason for having included the lame VB code as it was. I see your reasoning, but it's making an assumption about the people driving the technology, as opposed to the technology itself.



    That, my friend, is one messed up benchmark. It's more like a benchstain.



    It's bad.

  • My bad it looks like someone has picked up the project again. Should be interesting when they get done. All source code is available for each language and also the logs for each benchmark.

Comments have been disabled for this content.