A performance tidbits reference

  • Article

Imagine my surprise when I found that the Java Performance Tuning newsletter had linked to my blog (see https://javaperformancetuning.com/news/news046.shtml ) and imagine how much more surprised I was when they said this:

...Performance wise this blog on .NET performance by Rico Mariani, one of the CLR architects, shows that .NET still has some way to go in catching Java performance. "Less pointers and fewer virtual methods" to improve performance is not far from saying "program functionally"...

I hardly think that one can make any conclusions about which vendor has the edge in performance from my article on Performance Tidbits.  If I was to summarize my advice in that blog in a few words it would be "don't use OOP features that you don't need."

This is not to say that you should shun virtual functions, inheritance, or other features of modern programming languages.  Far from it, often they not only add clarity and maintainability they also improve performance.  But, as often, I find that people have written their code in some elaborate way when a much simpler model would have been equally servicable and more performant.  Whatever programming religion you may have I think you'll agree that more complex language abstractions do not inherently help your design -- rather each more sophisticated feature starts at a net negative and must somehow earn its way to positiveness with benefits such as clarity, ease of maintenance, performance, and so forth.

So when I say things like "don't use a delegates if regular polymorphism would do" I don't mean that you should avoid delegates I mean that you should not use them if they are overkill.

Now as to having less pointers -- nothing will kill your performance faster that bad locality of reference and nothing destroys locality faster than having datastructures that are a forest of pointers.  I think it's fair to say that there are no compilers that can save you from a bad datastructure.  On prevelant processors pointer proliferation is problematic (say that 5 times fast) .  It matters not which flavor of infrastructure you prefer.

Although my experience on other managed systems is much more limited, my impression, and the general feedback, has been fairly consistent that my advice with regard to the .NET framework is usually equally applicable to other managed systems.

I see no Kryptonite here :)

Comments

  • Anonymous
    October 19, 2004
    What I think he (maybe unknowingly) might be referring to is the capabilites of at least the JRockit JVM to devirtualize virtual function calls when there only exist one implementor of a virtual function, or make guarded devirtualization when there are only a few implementors, which is the majority of the cases.

    The jvm's have been forced to develop this kind of functionality since by default all public methods in java are virtual. Now that they actually have done it, it pays of with very low performance penalty for using virtual functions.

    The modern JVM's also perform profile guided optimizations, and one of them is when you have a virtual function where one instance of the virtual method is called in the vast majority of the cases. Under these circumstances, it may be beneficial to regenerate that method, with a guarded devirtualization of that popular method call.

    Since the .NET Framework seems fairly focused on startup times, and has taken the NGen path, I guess it's harder to do these kinds of things, since an optimization like that may have to be undone when a new class is loaded that implements the same virtual method.

    So, Rico, do you think you could elaborate some on the code generation strategy for the CLR? It would be nice to be able to compare it to the JVM's?

    Today, it seems to me like very fast JVM's are compensating for a very heavy J2EE architecture/class libraries to give roughly equal performace as the CLR/.NET Framework.

    But optimizations on the JVM's seems to be quite a bit ahead. This is only based on my personal observation (windbg attached to running instances of the JRockit jvm and the CLR 1.1, inspecting the generated code).

    Haven't looked at CLR 2.0 though... Any good news there?

    Thx

    /Staffan
  • Anonymous
    October 20, 2004
    This really deserves a much longer response than just a comment in here that hardly anyone will read. Let me do a little homework and I can at least write a regular blog entry on code-gen issues and cool stuff we did in Whidbey. Much of it was in the PDC bits of the Beta. I don't want to get too deep on code-quality issues because I try to keep my blog up a level from that but what the heck, I should say something :)
  • Anonymous
    October 20, 2004
    Microsoft performance guy Rico touches on a topic near and dear to my heart I hardly think that one can make any conclusions about which vendor has the edge in performance from my article on Performance Tidbits. If I...
  • Anonymous
    October 20, 2004
    "Haven't looked at CLR 2.0 though... Any good news there?"

    Well, not exactly...

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=c7de0148-8a78-45cd-b668-836a06ecffcf
  • Anonymous
    October 20, 2004
    Thank you for the bug report it's this kind of care that will help us to have as few accidental speed degrades as possible when making changes in this version. We have a huge test battery but stuff still sneaks through.
  • Anonymous
    October 21, 2004
    The comment has been removed
  • Anonymous
    October 21, 2004
    "new optimizations ... getting in each other's way."

    cough I don't cough know what you're talking about cough that ummm never happens :)

    Thanks extra for the feedback then.
  • Anonymous
    October 25, 2004
    Looks like it's fixed now... I can't wait to try out the next beta!

    (Interesting that there's no activity on it for months, then 3 days after I mention it in your blog it's fixed. Coincidence? :)
  • Anonymous
    October 25, 2004
    cough no comment cough :)